Not 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

Not 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.