We're open source, just came through the last YC batch. We use Postgres for the database, with an airtable-like editor in the dashboard. Since it's Postgres, migration is easy too - just dump your database and take it elsewhere
- Gather firebase's "true" API surface/interface, create a model in your typed language of choice. This might be easier/harder depending on how many special features there are... I haven't really seen openapi schemas for firebase, but that would make this really easy.
- Make implementations that don't save to firebase (and probably one that does, since it'd be very easy to write and would be a good baseline)
- Create a per-version fork of the firebase SDKs (ex. JS[0]) that points at your servers instead of Google's
- Offer a cheaper firebase (you could aim at Heroku customers?)
- Offer a painless migration from firebase as a feature
- ????
- Profit
Business model risks: Google lowering prices on firebase, doing this themselves, etc.
Asking because we started off with FireStore, getting a bit of traction now, but I can't see any good reason for us to switch away any time soon.
- Lack of schema makes it really easy write bad data without realising it. I inherited a 3 year old firebase/firestore codebase and database was FULL of inconsistent data. This was not helped by our application being in JavaScript meaning bad data could roundtrip all the way through our without triggering any errors. Only later causing obscure and hard to debug issues.
- Lack of query flexibility or joins make some use cases either impossible or very inefficient
- Connecting directly from client apps makes it very difficult to make backwards compatible changes. You can fix this by making everything go through backend APIs, but then you lose realtime which is the main benefit of firestore in the first place.
We're halfway through a port to Postgres+Hasura, and our app is much more reliable and responsive now.
You trade these things to get scale out:
- SQL joins and queries regardless of your schema.
- Enforcing public interfaces for reads/writes.
- Zero latency for admin operations.
- Global transactions.
- Auth logic written directly in your language, running where your data is.
The trade is not worth it if you do not use the scale out feature of Firestore.
I would just go with HTTP/websockets, typed language, SQLite and a single VM until you prove you need to scale out.
Also the pricing setup, im just not sure about it.
Currently i have decoupled all database layer operations behind a Repository service in Golang.
> Use our flexible, scalable NoSQL cloud database [called Firestore] to store and sync data for client- and server-side development.
Getting back to what the actual post was about, my first instinct is to find out a way to replace Firebase/Firestore as a dependency of Firetable though -- does anyone know of any API-compatible replacements for Firebase with pluggable backends (minio[0] is to S3 as <something> is to Firebase/Firestore).
I also... kind of think this might be good tech to spin a whole SaaS out of. It'd be unthinkable to try and compete with Airtable if I had to build their frontend but... hosting a database, giving access to shared/private instances of firetable, and trying to out-maneuver (or just undercut) airtable seems like it might not be a completely fool's errand.
[0]: https://min.io/
I am an expert yak shaver, so it would have probably been one of the first things on my mind.
Heads up: This seems to be built on top of Firestore. I'm not saying security can't be good[0], but it seems it can't be hosted locally.
[0]: In fact I guess in the long run the security of Firestore will be better than anything most of us can do at home.
That's why I'm not taking it for a spin just yet.
(alternativeto had a comment from June saying it was closed source.)
1. You can embed Airtables. Combine that with a Markdown editor and you have a powerful note taking device similar to Notion.
2. Public forms. Basically you can turn the table into a form and the data users enter into it become rows in an Airtable. Not achievable with Trello/Notion.
3. It has a functioning API, unlike Notion. I can add/retrieve/modify data via scripts/IFTTT/Zapier.
4. Org charts and Gantt charts.
Adding / editing in the Firebase admin UI is also time consuming.
The spreadsheet abstraction feels effective. I'm really looking forward to playing around with this.
(Also, seems like there's some confusion about the Firestore reference: https://firebase.google.com/docs/firestore).
I wouldn't quite compare this with Airtable because even thought the abstraction may look the same, the audience is very different: FireStore's audience is technical, while only a small fraction of Airtable's is technical, which leads to a different set of product priorites and likely a very different long-term roadmap.
