For those who aren't necessarily familiar with "Firestore" (I'd heard of Firebase but didn't know what Firestore was): https://firebase.google.com/docs/firestore

> 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/

Shams, the creator here. We built the MVP using Firestore but support for other DBs are on the roadmap.

Just want to say thanks for open sourcing this, there is an immense amount of value in here, surprised no one at Antler wanted to productize this!

should you exclude files such as https://github.com/AntlerVC/firetable/blob/master/www/.env.e... from the repo?

Its encrypted

Really great to have something that feels a lot like Airtable open source. If I had a wish I'd say decouple the database layer instead of providing support for more databases. Let the community help build abstractions and that way also open Firetable for non-public or embedded data stores/ data bases.

This is amazing! I'd suggest keeping focusing on Firestore until PMF and than expand to other dbs.

CouchDB: its APIs are not a 1-1 match but it feels the closest in spirit. Would love to know if there is another one.

It definitely might be the closest in spirit, but if the idea is just read and write documents in a document store, there is a lot of value in extracting the interface and allowing for multiple implementations.

I am an expert yak shaver, so it would have probably been one of the first things on my mind.

Beautiful. Our entire back-end is powered by FireStore and the admin UI is... lacking. We've been writing custom scripts and were even planning to build a bare-boned web app to easily let us perform certain actions without having to run a script.

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.

I loved using Firebase & Firestore to build MVPs, but I would advise anyone tempted to use it, to avoid it. Every time I've embraced it, I ended up having to rewrite apps shortly thereafter. Your app becomes unavoidably coupled to it.

For those looking for a suitable alternative, we are building https://supabase.io

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

What if I just want to use the auth module? With firebase, I get it for completely free.

Supabase is also free, and if you just want to use Auth that’s perfectly fine.

For how long though?

"While we're in alpha we are free to use. In the future, we will charge for hosting."

https://supabase.io/docs/pricing

heyyy I just got into the alpha today!! Excited!!

That’s great - feel free to email any bugs or feedback and we’ll fix it up ASAP

This seems like a pain point easily solved by a niche firebase-to-something-else migration tier. Seems like there's a small but possibly profitable company waiting to be created here:

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

[0]: https://github.com/firebase/firebase-js-sdk

Why not just use Postgres or another option that has all the features you need in the first place? What value is firebase providing here?

Sorry if it wasn't clear -- this is an idea on how to capitalize on people picking Firebase and then wanting out later. I think there's a similar business here for getting people off of some other famous data stores (particularly in the document storage space) as well -- not limited to firebase.

Trying to convince everyone in the world to use the right solution for their actual problem the first time (and effectively going against Google's marketing machine, momentum of the general project, discounted plans, etc) is not my cup of tea.

IMO the right database for the overwhelming majority of startups is Postgres, vertically scaled until it needs read-replicas. The extension ecosystem, burgeoning support for configurable table access methods makes it a no-brainer. I don't have sufficient experience to back this statement (I haven't run that many startups, I don't run an accelerator/VC, etc) but I'd love it if some else that could refute it would show up.

I don't think this line of thinking is wrong, as often it is better to just start with Postgres. But Firebase does offer some nice advantages at the start of a project.

1. Generous, hosted free tier. I don't have to fiddle with setting up a database or paying for it. And I really do mean generous. You can run a small business off the free tier if you code it in a way that doesn't use unnecessary reads and writes. I've done it.

2. Development speed. It's all schema-less, which is (sometimes) one less thing to worry about at the start of a project. Firestore is the fastest way to get a functional proof-of-concept I have ever seen.

3. Realtime. This means your frontend gets instant live updates out of the box. This can be pretty hard to achieve with other solutions, but comes free with Firestore.

4. Securely connect directly from the client. This means you don't need a backend at all, which is a huge win when you're just tinkering.

5. Amazing cross platform support. Setting up the connection to the database from iOS, Android, or Web takes a matter of minutes.

Now, a lot of these early wins come with growing pains later on. But early wins are still a great thing if it is the difference between your project getting off the ground, or failing from the start. I don't really use Firestore anymore, but there is a lot I liked about it.

What were the downsides of the coupling? Pricing? Lack of flexibility in the ways you could morph it?

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.

For our use case:

- 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 usually use a tool like fireward or bolt to manage schema for the security rules.

https://github.com/bijoutrouvaille/fireward

https://github.com/FirebaseExtended/bolt

I have seen people putting bad security rules often before. It makes me worried about using firebase apps.

No proper rate limiting, protected fields, dashboard sucks, opened feature requests for years without any answers, missing ton of small stuff I can't remember that is very easy to do on postgres (counters?), etc.

I have used hasura. It's good but I like supabase more now. Easier to directly write SQL than indirection of graphql.

Those security rules tools look excellent. I had no idea that security rules could restrict the data shape. Our app only has basic read permissions configured (and we're not bothering updating them because we're moving all the data our of firebase anyway).

> I have used hasura. It's good but I like supabase more now. Easier to directly write SQL than indirection of graphql.

Supabase looks really nice. I'd definitely consider it for new projects. The nice thing about Hasura is you have full access to the underlying Postgres DB. We are actually writing SQL for most of our data fetching needs with a traditional express backend. We're only going through Hasura when we need realtime capabilities. But it's pretty nice to be a bolt it on and get subscriptions out of the box :)

It's the same for supabase without the additional graphql layer. It runs a separate elixir project to convert postgres changes into real time subscriptions. You can use this without using other parts.

https://github.com/supabase/realtime

An architecture I've seen work is to have reads be direct from the client, but writes be through cloud functions. You can then do migrations and denormalization in the functions and the client sees the sync events as the write completes.

I do wish they'd add actual migration support though. Firebase has always needed some kind of document views like feature to allow backwards compat, but still allow changing the schema.

I don't understand why people are so keen on these "serverless" architectures. Why not just run a backend web server. It's generally the least troublesome part of the system, and it buys you a bootload of flexibility.

I've used Firestore in the past, and would not use it unless you absolutely require the scale out.

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.

I've heard that it's very expensive.

I'm currently using cloud datastore.. But tempting to use firestore cause its easier in the app... However my raw data schemas are often not exactly what i want to expose to the app.. I know it solvable with firestore, but only with firestore's solution..

Also the pricing setup, im just not sure about it.

Currently i have decoupled all database layer operations behind a Repository service in Golang.

Vendor lock-in is indeed a concern, but IMO the biggest concern is that Firebase only really works for MVPs. It's super easy to go from 0 to 10, but painful or even impossible to go from 10 to 100.

I'm honestly really excited by this. Airtable transformed my spreadsheet experience, and I've long wished for something I can self host locally to be able to store more sensitive data (like bank statements).

> and I've long wished for something I can self host locally to be able to store more sensitive data (like bank statements).

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.

The dev here commented that Firestore was used for the MVP and that they're planning on supporting other DBs in the future: https://news.ycombinator.com/item?id=24636238

That's why I'm not taking it for a spin just yet.

Another open-source alternative to Airtable is Baserow. Looks like it's a bit more basic than Firetable, but they have a good road map posted on their website.

Opened sourced in July it seems: https://gitlab.com/bramw/baserow

(alternativeto had a comment from June saying it was closed source.)

I'm still confused by what usecases Airtable or this has. Are there any for project management/app design and dev that can't be done by Trello/Notion?

Airtable is basically more like an online version of MS Access/dBase/FoxPro, database + forms/presentation. So it's very customizable and you can essentially roll your own project management app, or CRM or whatever you can think of.

As someone who used all of those notes:

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.

I recently took a look at glideapps.com which I thought was quite cool. It really surprised me how much of an app you can build with nothing more than a spreadsheet. This seems similar.

Whats the table library used here?

React-data-grid

How was your experience with react-data-grid? I've heard it can be painful to work with sometimes?

So this was something built internally inside a VC firm and then opensourced?

Hi Harini here, I lead technology at Antler, a global VC. We built this for internal use at Antler and decided to open source it as we felt lot of startups can benefit from it and avoid having to built yet another admin portal. We are actively working on adding features and improving the project.

This is open source under Apache-2.0 License.

Will definitely try this

I think the implication is that Firetable is an open source "Airtable".