spicedb icon indicating copy to clipboard operation
spicedb copied to clipboard
verified publisher icon authzed

Implement a TiDB datastore

Open jzelinskie opened this issue 4 years ago • 7 comments

Creating this issue to gauge interest

jzelinskie avatar Sep 30 '21 20:09 jzelinskie

Personally, not using TiDB but would switch if postgres ever fails to scale for us.

MySQL differences:

https://docs.pingcap.com/tidb/stable/mysql-compatibility

https://docs.pingcap.com/tidb/stable/pessimistic-transaction

https://docs.pingcap.com/tidb/stable/security-compatibility-with-mysql

MateusAmin avatar Sep 30 '21 21:09 MateusAmin

Is there a plan for supporting TiDB datastore?

teckick avatar Oct 15 '22 08:10 teckick

I've spent some time looking into this and I'm not sure if it makes more sense targeting TiKV or TiDB.

jzelinskie avatar Oct 16 '22 03:10 jzelinskie

@eastfisher are you still interested in a TiDB datastore?

josephschorr avatar Mar 21 '23 17:03 josephschorr

TiKV, no doubt. Unlike TiDB, TiKV is a graduated cloud native foundation project, a guaranty of long term support and far less likely to move to an Affero style license.

modalgap avatar Jul 01 '23 02:07 modalgap

@jzelinskie @josephschorr Is there a description somewhere of what operations a datastore has to support in order to work as a SpiceDB backend and what needs to be performant? Thinking idly about the possibility of hooking up SpiceDB and we're currently TiDB users so wondering about the lift here.

For context, right now there's three versions:

  1. TiKV v1 - has transactionality but hard coded MVCC garbage collection and doesn't play nicely with the same TiKV cluster also being used for TiDB. Now deprecated.
  2. TiKV v2 - uses the same MVCC garbage collection and internal encoding as TiDB so can peacefully coexist in the same cluster.
  3. TiDB - full SQL layer - some overhead due to MySQL layer but also includes indexing, etc. etc.

I think most appealing for us would be TiDB but I can see how people who aren't otherwise running TiDB might find raw TiKV more appealing.

frew avatar Jul 11 '23 18:07 frew

@frew the most important requirement is to be able to serve strong consistent reads. This is needed to support zedtokens and address the new-enemy problem. Having Snapshot Reads and Change Stream support is definitely a plus, but it can also be layered on top of the database.

TiKV could be enough as long as you are able to support multiple read access patterns (to support different types of queries). I don't know how that works at the TiKV layer but I assume it's not different from what you'd do with Cassandra, where you have to either manually denormalize (or use materialized views). In that sense using the TiDB layer may be simpler.

Have you considered exploring modifications to the current MySQL datastore driver to support TiDB?

vroldanbet avatar Jul 12 '23 12:07 vroldanbet