TB as a Corner Stone

[theHamdiz]

Hey there,

I hope I am not bothering you as this is my second discussion.

I was thinking that Frameworks come and go, yet some thrive. those who do typically fall under a certain category.

composability, working with TB as the corner stone and building around it is what will get people to use it as the defacto framework in itself.

Meaning, while SQLite is awesome, I see no reason not to use Adapters & Bridges and just support multiple db. systems. or at least PostgreSQL as the major server based relational db. system and mongo db. for NoSQL.

This will enable developers to start using TB as their corner stone for building almost anything.

I am not really keen on supporting only SQLite like pocketbase I see the potential here for more.

I hope my words meant something.

[ignatz]

Meaning, while SQLite is awesome, I see no reason not to use Adapters & Bridges and just support multiple db. systems. or at least PostgreSQL as the major server based relational db. system and mongo db. for NoSQL.

Partly. It's not quite as easy as just throwing in an ORM to abstract over databases. Things like data-change subscriptions go beyond ISO SQL. Technically anything is possible but it would require substantially divergent integrations. In practice I'm not aware of any DBaaS/Base product that supports multiple DB backends (Firebase, PocketBase, Supabase, AppWrite, ...). The last point is non-technical whataboutism but maybe still noteworthy.

On the more technical side, I'm also not sure that every integration needs to be or should be mitigated through TB. If you need a more specialized solution, e.g. for performance reasons, you should just be able to add it. If you want Mongo, SkyllaDb, Cassandra, vitess, redis, valkey, .... , TB shouldn't get in the way. You should be able to just use them from your own backend or even TB WASM components.

Ultimately, with options many and resources limited there will always be a limit to what we can do. I'd prefer to talk about specific problems, goals and how to solve them, as opposed to jumping to implementations.

Not to push you away, I'm genuinely curious: if you're looking for Postgres specifically (which is a great DB), have you looked at Supabase? Why TrailBase in your case?

[theHamdiz]

I’ve taken a close look at Supabase before, and while it’s a solid BaaS, there are still cases where an in‑house approach makes more sense. Two things stand out for me:

• Latency in high‑volume, data‑intensive applications where performance is critical.
• Cost considerations once you start scaling beyond the comfort zone of managed services.

That’s why I keep circling back to PostgreSQL. It feels like the most complete and standardized relational database we have — not just because of its maturity, but because of the breadth of features it brings: full‑text search, geospatial support, advanced concurrency, and proven scalability. Having first class support for it would be a big deal in positioning TB as a serious cornerstone for developers.

“I’d prefer to talk about specific problems, goals and how to solve them, as opposed to jumping to implementations.”

You’re absolutely right, and I probably jumped too quickly into implementation talk. My intent wasn’t to suggest TB should abstract everything, but rather to propose a focused integration strategy: one canonical option per category. For relational backends, that would mean PostgreSQL. This way TB offers a strong default without blocking developers from plugging in specialized solutions when needed.

Over time, this could even evolve into build‑time “versions” — optimized configurations that balance performance, binary size, and dashboard complexity depending on the use case. That way TB stays lightweight and composable, while still giving developers a reliable, standardized foundation to build on.

[ignatz]

I’ve taken a close look at Supabase before, and while it’s a solid BaaS, there are still cases where an in‑house approach makes more sense. Two things stand out for me:

* **Latency** in high‑volume, data‑intensive applications where performance is critical.
* **Cost considerations** once you start scaling beyond the comfort zone of managed services.

I'm a bit puzzled. Supabase can be self-hosted. If TrailBase's implementation would converge towards Supabase's implementation (e.g. using Postgres), presumably its performance characteristics would converge towards Supabase's. TrailBase's implementation is what allows it to have lower latency at a lower cost.

That’s why I keep circling back to PostgreSQL. It feels like the most complete and standardized relational database we have — not just because of its maturity, but because of the breadth of features it brings: full‑text search, geospatial support, advanced concurrency, and proven scalability. Having first class support for it would be a big deal in positioning TB as a serious cornerstone for developers.

FWIW, I love Postgres just as much as everyone else. It may not be the most scalable but it has solid performance (certainly sufficient for most users) while being an absolute Swiss army knife. I did hope for a while that PGLite could be a cool middle-ground giving us some of the properties of SQLite with the versatility of Postgres... but it doesn't seem to be the direction the project is going.

“I’d prefer to talk about specific problems, goals and how to solve them, as opposed to jumping to implementations.”

You’re absolutely right, and I probably jumped too quickly into implementation talk. My intent wasn’t to suggest TB should abstract everything, but rather to propose a focused integration strategy: one canonical option per category. For relational backends, that would mean PostgreSQL. This way TB offers a strong default without blocking developers from plugging in specialized solutions when needed.

I'm not sure if it's focused. I'm not sure what the problem is you're trying to solve? Postgres is the implementation.

I also think Postgres is as popular and awesome as it is because it isn't focused, it isn't a specialized solution. It let's you dabble in relational, FTS, vector, time-series, columnar, ... DBs w/o requiring yet another thing.

What problem are you trying to solve, where you feel TB in its current shape would be insufficient? Maybe even more critically, couldn't be solved going forward due to inherent architectural limitations? (FWIW, SQLite can support geospatical, vector, FTS, ...)

Over time, this could even evolve into build‑time “versions” — optimized configurations that balance performance, binary size, and dashboard complexity depending on the use case.

I'd be a bit worried about UX. Maybe you could point to something similar to what you have in mind, so I can get a better sense of how this could look like?

FWIW, small binary size, solid performance and a simple dashboard, are some of the aspects that informed the current architecture.

That way TB stays lightweight and composable, while still giving developers a reliable, standardized foundation to build on.

👍 We're on the same page, that's what TB is trying to achieve.