4 ms·
> Microservices and NoSQL get a lot of hype, but in many cases what you really want is a relational database that simply works, and can easily scale as your app
by matt_wulfeck 10y ago
> Microservices and NoSQL get a lot of hype, but in many cases what you really want is a relational database that simply works, and can easily scale as your application data grows.
I believe this product is very threatened right now by Google's newly announce Cloud Spanner database[1]. Even with services like this that make scaling "easy", it doesn't yet make it transparent like Google is striving to do.
[1] https://cloudplatform.googleblog.com/2017/02/introducing-Cloud-Spanner-a-global-database-service-for-mission-critical-applications.html https://cloudplatform.googleblog.com/2017/02/introducing-Clo...
- craigkerstiens 10y agoCraig here from Citus. Spanner is absolutely some interesting technology, but focuses on some pretty different use cases than we're looking to solve. Spanner is globally distributed but the cost of that is likely to be 100ms per operation. Further it uses SQL for the read, but the insert and update is RPC so it's a bit of a different interface. Citus is much more focused on interacting like a relational database that simply scales out as opposed to re-inventing a lot of the underlying tech and interfaces. You can find the comment further down from one of our founders, but we're very focused on a few use cases. 1. Scaling beyond single node Postgres (this primarily for B2B applications currently) 2. Operational analytics, here because of the way we parallelize the workload you can get sub-second query performance across terabytes of data. 3. NoSQL++, this is a bit more akin to where spanner may fit, where you have exceptionally high read and write throughput requirements. (Exceptionally high meaning north of 100k writes per second).
- lobster_johnson 10y agoNot really, for several reasons. One is the fact that Spanner is a purely hosted service. That rules it out for a lot of folks, and for those shops where it's fine for production, it's inconvenient for developers. Your app is no longer something you can run completely on your laptop; and if you ever want to be able to develop offline, you have to architect your app to abstract the data layer so you can swap in something like Postgres. Spanner, as a relational database, also has some important limitations. For example, while nominally ACID, the "C" in ACID has historically included referential integrity, aka foreign keys, which Spanner does not currently do (presumably because doing this in a transaction would require locking the referenced row). Citus can use foreign keys between colocated tables, which enables certain apps where referential integrity is an absolute must (e.g. anything in finance). If you're used to functional indexes, partial indexes, PostGIS, fulltext, GIN (array indexing, very useful), the superbly rich SQL dialect (COPY FROM/TO, SELECT INTO, CTEs, window functions, LISTEN/NOTIFY, timezone-aware dates), triggers, etc. then migrating to Spanner means potentially dividing a lot of that up to pieces. For example, the lack of fulltext support might mean having to resort to something else, like Elasticsearch, to supplement the database; now you have a rather different system that requires some kind of stateful firehose for indexing, instead of a single transactional RDBMS. There are pros and cons to everything. Spanner looks very impressive, but it's not for all apps/shops.