Hi there! One thing you might consider is using a function to replicate your Firestore data to BigQuery, depending on the value the latter would add. (Very fast OLAP; I'm a big fan.)

(Cloud Firestore eng. here.)

Hi there. :) I'm an engineer on the Cloud Firestore team. I can't speak to if or when we'll be able to remove this restriction, but please know that the folks working on this (like me) are very aware of what a pain in the butt this is. I'm sorry that I can't give you a more satisfying answer, but I hope we'll be able to change this soon. Thanks for being a customer!

Cloud Spanner is also relational. :)

(Fellow GCPer.)

An export is one component of a backup solution. :) Scheduling is another (https://firebase.google.com/docs/firestore/solutions/schedul...). (Checking restores is critical, too; that's also feasible [managed import into a new cloud project] but requires a bit more legwork.)

(I work on Cloud Firestore.)

FWIW, I'd love it if you made my app unnecessary. You can consider my site a list of feature requests :)

Is there anything we could be doing to serve you better?

Yes, let me run datastore on my servers. Surely I may use your cloud offer but in certain cases I need to run it on my servers. I can't build/invest in tools/drivers for a proprietary cloud service.

a) Cloud Firestore supports transactions across the entire database. You can learn more about them here: https://cloud.google.com/firestore/docs/manage-data/transact....

b) Given that the primary use case for namespaces was/is multitenancy, it's not clear to me why you'd want to transact across them. Nevertheless, you can. What's leading you to draw this conclusion?

The documentation is what led me to that conclusion, since it's not explicit as to what the transaction boundaries are, but I could be mistaken. Does this mean that the poster's claim is erroneous?

It does. It's not in the documentation because it doesn't have boundaries within the database.

Can you have more than one database per project? If so, there still might be a valid claim here.

Cloud Firestore (the next generation of Cloud Datastore) removes those limitations. https://cloud.google.com/firestore/docs/manage-data/transact...

It also supports the Cloud Datastore API.

(I work on it!)

Hey there--I'm an engineer on the Cloud Datastore team. I'd love to know more about what your needs are if you're willing to share.

He "needs" to get rid of you (Google). :-)

I've forked the official SDK so that I can get extra functionality but it's quite hard to keep it updated when internal stuff changes. There is no way I can contribute. I can't use it everywhere I want...shortly said it's not open source and this sucks.

This (fantastic) paper is cited in the Google Megastore paper [1] and we actually use the term "entity group" in our product [2] indirectly because of it. Pat Helland is always worth reading; thanks to the submitter for the reminder.

[1] https://static.googleusercontent.com/media/research.google.c...

[2] https://cloud.google.com/datastore/docs/articles/balancing-s...

I would need to read it again, but it smells a lot like high platform availability combined with small traffic, and it looks like a pita to support it (except for the cases where they refuse to support the customers)

It is really worth reading for anyone doing any highly scalable services (micro or not). This article just pin point any issue we have stumbled on in my current job.

Have a look at https://cloud.google.com/compute/docs/load-balancing/ipv6.

(Disclaimer: I work on GCP, albeit not on networking stuff.)

That's not helpful for a wide range of use cases. The most recent one I ran into was running an irc server that would be compatible with the matrix irc bridge, see https://github.com/matrix-org/matrix-appservice-irc/issues/2...