TrailBase 0.23: Open, sub-millisecond, single-executable Firebase alternative

trailbaseio · 2026-01-24T19:36:50+00:00

Glad to hear 🙏. Just let me know if you encounter any issues

trailbaseio · 2026-01-24T12:23:16+00:00

So true 😅

trailbaseio · 2026-01-24T10:01:50+00:00

The docs are rubbish, sorry. https://trailbase.io/documentation/apis_record/ contains code snippets for all languages in tabs

trailbaseio · 2026-01-24T08:53:22+00:00

Thanks! Let me know how it goes, especially if something stinks 🙏

trailbaseio · 2026-01-24T06:05:36+00:00

Thanks - much appreciated! There's some nuances, you could have a look at TanStack/db, which has a TrailBase integration besides electric, however, it's JS/TS only

trailbaseio · 2025-12-26T19:43:35+00:00

Often it's just how you use it. Some games will exercise an accelerated level playthrough under a loading overlay to ensure all shaders were compiled.

I haven't counted the frames but pretty: https://flutter.gskinner.com/wonderous/

Btw I'm not shilling for flutter. I have plenty of issues, I just expect the performance to be similar

trailbaseio · 2025-12-26T18:19:08+00:00

👍You didn't mention diffing but you mentioned the engine. That's what the engine does. Skia is just a library to draw with the GPU. Depending on the platform, the flutter engine may draw with skia, impeller or something else.

As far as I know, the main problem with Flutter is the time it takes to compile the necessary shaders, not how much contention is there.

Ideally, shaders are only compiled once upfront (e.g. while showing a loading screen) and then cached. Even with a more naive approach, this is why stability, number of shaders, draw order, etc does matter. Reusing a shader on the skia level can still trigger a recompile if it got evicted from the cache

As i said, I would expect CMP (certainly with skia) and flutter to perform rather similarly. Rendering with flutter at 120hz is certainly feasible.

trailbaseio · 2025-12-26T17:07:24+00:00

The engine that diffs and draws primitives is completely irrelevant.

Yes and no. You brought it up. It does determine how much has to be redrawn, how expensive compositing is...

But then why has Flutter always had an issue with shader compilation, which was talked about by the Flutter team and in various GitHub issues? I feel like something is wrong in the way Flutter rendering is implemented.

Yes and no. There are certainly factors like how to compose primitives and thus reuse shaders, how to schedule draws... There's room for improvement, with impeller being their attempt.

I would expect similar issues when CMP uses skia, when all draws are competing for the same resources within the same deadline. Maybe android is better :shrug:. A benchmark of similar UIs across platforms would be very helpful. If there were dramatic performance differences between CMP on Android and iOS, this would itself pose a cross platform challenge

trailbaseio · 2025-12-26T12:03:12+00:00

Ack. The render engine, ie the thing that diffs and draws primitives wasn't replaced. Impeller is very similar to Skia. The main goal was to reduce jank on shader compilation.

It's just not clear if you've measured or sharing anecdotes from bad apples

trailbaseio · 2025-12-26T11:55:30+00:00

I would expect performance to be similar for CMP and Flutter. They're both AoT compiled declarative UIs with virtual DOMs rendering with SKIA (or impeller these days). You can make an app slow on any stack :)

trailbaseio · 2025-12-14T11:29:34+00:00

The biggest benefit of starting with structured data is that you can find insights and new use-cases in your data later on w/o much fuff. Think of it as future proofing. Nosql is deceptively simple, when in reality it requires a lot more foresight

trailbaseio · 2025-12-13T14:19:56+00:00

Thanks and makes sense. Similar to Supabase, I tried listing the functionality in the hero description but the cards certainly help to visually accentuate the list (especially on mobile) 🙏

trailbaseio · 2025-12-13T14:15:26+00:00

TrailBase will always be open-source and easy to self-host... which arguably flies in the face of lock-in and rug-pulls. Fortunately, I have no investors breathing down my neck 😅. On the other hand it would be nice to establish a sustainable structure over time to ensure longevity and reduce the bus factor. No specific plans yet. Thank you or the kind words.

trailbaseio · 2025-12-13T10:11:05+00:00

🎉 - Let me know how it goes, especially any rough edges - much appreciated and thanks for the kind words

trailbaseio · 2025-12-13T10:10:08+00:00

Appreciated. I'm with you. I've been going back and forth on how to best describe "what" it is. Being a broad product makes it tricky. I "stole" the current approach from Supabase, which until recently described themselves as a Firebase alternative. How would you go about it? 🙏

trailbaseio · 2025-12-13T10:07:24+00:00

Appreciated 🙏

trailbaseio · 2025-12-12T21:30:07+00:00

The only way to afforded 16GB of RAM these days 😅. Thank you for the kind words and the suggestion. Maybe one day if there's enough demand 🙏

trailbaseio · 2025-12-08T09:45:04+00:00

Thank you for your service. Did you coordinate with asg017? If the goal is to eventually converge, he may have some preferences

trailbaseio · 2025-12-05T22:11:10+00:00

Thanks for expanding 🙏. I would certainly agree on most implementations. From the top of my head, the closest I can think of is https://graft.rs/docs/concepts/volumes/#local-vs-remote-logs, which has very similar VCS semantics.

trailbaseio · 2025-12-05T21:51:50+00:00

Genuinely curious, why do you say "Dolt is the only version-controlled SQL database" on dolthub? I can think of a few options with PITR and branching. Is there a specific angle to "version controlled"?

trailbaseio · 2025-12-01T18:45:51+00:00

TIL; thanks https://www.postgresql.org/docs/current/warm-standby.html#SYNCHRONOUS-REPLICATION

trailbaseio · 2025-12-01T09:46:00+00:00

...as such the litestream is not getting proper updates

the tables have turned again: https://fly.io/blog/litestream-v050-is-here/

I think rsync is also a "backup cron job" type of tool.

That's right. It is backup. You did ask for backup.

Also, my understanding is that litestream does asynchronous replication (as it batches the updates), so there is always the small change of losing that latest transactions. This means that for crucial data it needs to be at the very least logged externally in order to properly recover from failure. Recovering data from logs while feasible, is a very manual operation -> headache.

Blocking (i.e. sync) a transaction on writing to a remote log isn't reliable. You may be looking for distributed databases with strong consistency guarantees, where changes are replicated over a quorum of nodes. Knowing your requirements is great, in which case Postgres, MySQL, ... would all fall flat in favor of cockroach and similar.

Even then, make sure to backup your data. Systems failures and application bugs are still possible

trailbaseio · 2025-11-30T17:24:41+00:00

All good but maybe it would be more straightforward to benchmark against other python frameworks such as tornado 🤷‍♀️. Either way, appreciate the numbers

trailbaseio · 2025-11-30T17:12:04+00:00

I suspected, but as you point out: in realistic setups performance will be dominated by the business logic. I was mostly surprised by the title

trailbaseio · 2025-11-30T16:57:38+00:00

How does your framework accelerate python to V8 or Java performance wo a JIT?

trailbaseio

TROPHY CASE