Database record limits

Ideas & Features
1

Hello Fibery team! :slightly_smiling_face:

I know there was a similar discussion several years ago regarding entity limits and scalability, where the answer was essentially:

“There are no hard limits — it depends on usage patterns, views, formulas, relations, etc.”

I wanted to revisit the topic because the context feels quite different today. :face_without_mouth:

With AI rapidly increasing productivity, teams are generating much more data than before — entities, logs, generated assets, historical records, automations, relations, supporting objects, and operational records.

A few years ago, numbers like 300k entities sounded enormous. Today, they honestly no longer feel that huge when thinking about long-term operational systems powered by AI.

And questions like:

  • At what scale should teams realistically expect performance degradation?

  • Is ~300k entities still considered a relatively “comfortable” range for a well-architected workspace?

  • Are there practical or hard limits today that teams should plan around?

At the same time, it feels like the market is moving in this direction. For example, platforms like Airtable introduced larger-scale data approaches because power users and enterprise teams increasingly need confidence that they can continue scaling without running into ceilings or major performance concerns (HyperDB with record limits in the hundreds of millions).

From a corporate perspective, I suspect many teams would actually be comfortable paying more for this confidence.

Something like:

“If you are a power user / enterprise customer and need significantly larger scale with predictable performance, here are higher limits or scaling options”

would probably be completely acceptable for many companies.

In enterprise environments, willingness to pay is usually not the biggest blocker — predictability, reliability, and confidence that systems will continue working at scale matter much more.

So the main question is:

How should teams think about long-term scaling in Fibery today, and are there any plans or ideas around higher-scale options / limits for power users or enterprise workspaces :thinking: ?

2

So far we don’t see any significant demand for that and I am not sure that AI-related workflows will indeed generate like 10x more data. For enterprise we indeed can provide dedicates isolated hosting that will make performance more predictable. However, at this very moment we are doing nothing here. Later this year we will focus on performance improvements and it should lead to higher limits.

Note that even in Airtable for Enterprise they have 500,000 records per base. For the record, these are top database in all fibery workspaces by entities count. As you see, some accounts do get millions of records, but we just can’t guarantee any good performance in such cases. ~300-400K should work fine.

Screenshot 2026-05-29 at 3.31.23 PM
Screenshot 2026-05-29 at 3.31.23 PM628×1384 39.7 KB

3

Thank you so much for the quick and detailed reply — really appreciate it!

And honestly, this discussion reassured us quite a bit :slightly_smiling_face:

We genuinely love Fibery and, for our use cases, still consider it a stronger system than Airtable in many ways — this conversation actually reinforced that feeling again :slightly_smiling_face: .

Just as an additional data point (in case it is useful for your product thinking): our case may not be the most typical Fibery use case.

We are a company with a full cycle around our own mobile apps, and one of our operational areas is large-scale creative production for those apps. Over the last year, both for us and competitors (and we know it :face_without_mouth: ), the amount of tasks=content (creative production) has been growing very aggressively — sometimes x2, x3, x4 … year over year.

So part of our concern comes from seeing how fast operational data generation is accelerating in AI-assisted environments.

That said, we completely understand this may not represent the most common customer profile — just wanted to share it as an example in case it is useful context :slightly_smiling_face:

And thank you very much again :+1:

4

I’d love to add one note here as I worked with a database with 500,000 records in Fibery.

We imported around 50k records from a csv at a time. The problems arose during import specifically. It would result in significant delays of automations, formulas, and auto-linking.

This is because each workspace has a single engine for each. As you can see here:

Screenshot 2026-05-29 at 14.16.37
Screenshot 2026-05-29 at 14.16.37578×398 25.1 KB

Since this database was using these services, each import would bog down the full workspace until the queue finished running.

The solution we came up with was to import on non-working hours.

If your 500k database has no formulas, auto-linking, or automations, I wouldn’t expect any problems with just storing the data. Just storing the data doesn’t influence the performance, its overloading other services and loading the data into the UI which does. Viewing all data at the same time in a table would take a long time to load or time out completely. But not sure why that would even be useful!

A potential solution (@mdubakov) for this is a separate engine per database/space. Then one database triggering these services would not affect the others. Not sure if this is feasible/expensive.

Also, @ID.000 if you want to perform bulk operations on the data, (delete all, or a button automation), it times out. You can do up to 3000-5000 at a time roughly.

But if I understand you correctly, its just normal day to day use, which will eventually generate a lot of data, right? It’s not manipulating large amounts of data regularly? Or needing a report on a large dataset (reports currently have a max 200k entity limit)?

If so, I think you should be safe.

5

We actually ran into something similar as well :slightly_smiling_face:

At first we did not even understand what happened or why some automations suddenly seemed not to run :grinning_face: .

In our case it was not critical — they eventually executed later, so everything was fine. I think at that moment we were doing something around ~5,000 automation executions / updates in a batch.

We ended up with a very similar conclusion: since this was mostly one-time database population and not day-to-day operational work, it was easier to run it during non-working hours and we did not experience any major issues after that :+1: .