search

temporalio / temporal

Temporal service
https://docs.temporal.io
MIT License
12.05k stars 849 forks source link

Any plan to support MS SQL Server? #3769

Open raymondsze opened 1 year ago

raymondsze commented 1 year ago

Temporal is awesome! I read the documentation and tried the typescript examples. It do solve the current issue I am facing on distributed transaction. However, I found that Temporal officially support MySQL and Postgres. We are working on on-premise product and some customers require MS SQL Server for the persistence. I would like to ask if there is any plan to support MS SQL Server. I found https://gitlab.com/lercher/temporal-sqls, but it seems not official.

raymondsze commented 1 year ago

any update?

adeal commented 1 year ago

My org (Salesforce) is also interested in support for Sql Server as the underlying persistence store.

Is this being tracked as a feature request? We're open to ideas of making the initial contribution to the Temporal server.

samarabbas commented 1 year ago

Hey @adeal currently there is no plan to support MS SQL Server is the persistence plugin. Initial contribution of the plugin is one concern but the bigger problem is ongoing cost of maintaining the plugin. Ideally we would first refactor the persistence which allows these plugins to reside in separate repos and injected at runtime. We also need to refactor the testing infrastructure where these plugins can be tested in a generic fashion. Once we have this setup, then we can have external contributors provide and independently support plugins for other data sources.

plaisted commented 8 months ago

I've been tinkering with temporal persistence as a way to understand how things work a little better and was wondering if adding a built in grpc persistence implementation would be possible. It appears the storage is already abstracted into a set of interfaces. General idea would be to add a built in "grpc" persistence where configuration would be supplying an endpoint (or endpoints) + TLS information. The endpoint would then be responsible for implementing all the required grpc calls based on the existing persistence interfaces.

This would serve the same purpose as a golang plugin architecture but allow the standard temporal distribution (containers, binaries) to use custom persistence without modification (just add configuration). Obviously this comes at some performance cost (serialization, network hop) but thought I'd mention and see what people thought.