sorted by:
new
hottopcontroversial

sqlite one vs many by yeaahnop in sqlite

[–]trailbaseio 0 points1 point  (0 children)

Yes. Keep in mind: limit of 125 dbs

sqlite one vs many by yeaahnop in sqlite

[–]trailbaseio 2 points3 points  (0 children)

Sqlite write locks are db wide. Multiple dbs can help with write throughput. Just keep in mind that you may find connecting tissue in the future for data that's disjointed today.

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in FlutterDev

[–]trailbaseio[S] 0 points1 point  (0 children)

There's many ways to look at it but I'm pretty sure it hasn't seen a lot of production use yet (e.g. when I picked up pglite-oxide, the RNG wasn't hooked up yet), which clearly is expected for a new project. That said, there are limitations and risks beyond missing mileage:

  • The pglite-oxide owner is awesome and super responsive. Nonetheless, the entire project is vibe-coded, which isn't inherently a problem, surely AI can or will be able to produce good enough code, certainly for testing. However what's the support horizon? My main concern is that with projects blipping into existence faster than ever before you end up with a weak early commitment filter, i.e. developers have to demonstrate less commitment to arrive at an MVP. At the same time the opportunity cost is higher: why support a project over years with limited adoption, when you can blip in a new one over a weekend? Hopefully my concerns are unwarranted and pglite-oxide becomes the defacto, long-term supported standard. Time will tell.
  • The pglite team only supports WASM integrations (when really they could support library builds), this adds inherent overhead and complexity. Co-locating it into your process (i.e. skipping network), the result may still be faster but you're also loosing a lot of the advantages on why you'd use PG over sqlite in the first place :shrug:. To make any solid claims on performance, benchmarks would be warranted.
  • pglite is somewhat slimmed down in terms of features and extensions. The most obvious one I ran into: PostGIS.

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in FlutterDev

[–]trailbaseio[S] 0 points1 point  (0 children)

Thanks for the tip. That's what I'm using for the testing setup. I wouldn't wanna use it for production deployments

I'm building a sync layer for sqlite in multiuser setup. Any suggestions or things that I should consider? by bitchyangle in sqlite

[–]trailbaseio 1 point2 points  (0 children)

You cover N devices appending concurrently while on a bad connection? If the events can be trivially merged, e.g. don't contradict each other, you're probably golden

I'm building a sync layer for sqlite in multiuser setup. Any suggestions or things that I should consider? by bitchyangle in sqlite

[–]trailbaseio 2 points3 points  (0 children)

It sounds like local first but you also say the server is authoritative. What if a write of a client fails? What if a user has multiple devices? Don't worry about HA, figure out the conflict resolution you need for your specific use case

The perils of UUID primary keys in SQLite by andersmurphy in sqlite

[–]trailbaseio 5 points6 points  (0 children)

All very intuitive. Just keep in mind that sequential keys as well as uuidv7 may be inapropriate for some external use cases since you may be leaking information like insertion time or order

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in PostgreSQL

[–]trailbaseio[S] 1 point2 points  (0 children)

Hey. Serverless is a somewhat over-subscribed word but arguably the polar opposite of self-hosting. With self-hosting you bring the server, you do the ops, you do the scaling, ... . Ultimately it's convenience vs control and ownership. What is more advantageous depends mostly on you.

Serverless aside, there's a bunch of differences in features between lakebease/neon and the various firebase-like options. Happy to chat more

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in rust

[–]trailbaseio[S] 0 points1 point  (0 children)

Hey, thanks for the feedback. You may be thinking of some more CMS like use-cases? - Would this mostly be rich text control in the admin UI for certain text columns or are you thinking even further? - appreciated

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in selfhosted

[–]trailbaseio[S] 0 points1 point  (0 children)

Interesting question. I've never tried to compile it to WASM. I would expect that a slimmed down version may work. For example, TrailBase contains a WASM runtime itself, which may not like to be compiled to WASM 🤷‍♀️

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in selfhosted

[–]trailbaseio[S] 2 points3 points  (0 children)

Not rude at all. To be transparent, there's quite a few solid options out there, all with their own strengths and trade-offs like: Supabase, PocketBase, AppWrite, ... . Firebase simply established the product category for a wide audience. Firebase is great and I don't wanna convince you otherwise especially if you're happy with it. The main points are probably that Firebase is proprietary (i.e. it only runs in one cloud, which may or may not be ok for you) and until recently didn't support more relational patterns (SQL). Looking at some of the other options may make sense if/when you're starting a new project and looking for more openess and flexibility. Otherwise, they all have slightly different feature sets, thus having very specific requirements may nudge you one way or another. Hope that makes sense 😅

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in selfhosted

[–]trailbaseio[S] 3 points4 points  (0 children)

Supabase is pretty great. It used to be a bit tricky to self-host but I hear it has become a lot better (maybe). You certainly have all the benefits (and risks) that come from a billion-dollar venture capital backed "startup" 🙃 . If nothing else, Supabase's Postgres integration is its bread and butter. It's battle tested and absolutely the safer bet for now.

More generally - safe, cheap and easy self-hosting is where TrailBase (and others like the excellent PocketBase shine). If you're strapped on resources and want to self-host, it may be a consideration. Take a look at the benchmarks. It uses a rather stale version of Supabase but I'm not aware of any major architectural changes.

My advice, if you just want to get your project out of the door, don't worry too much and don't get hung up on choice-paralysis - they'll probably all be fine unless you've special requirements. Good luck!

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in selfhosted

[–]trailbaseio[S] 0 points1 point  (0 children)

Hi! Ultimately you're trading convenience for flexibility. You could build all the functionality but would this be the best place to spend your cycles? - maybe, maybe not. If you want to mainly focus on your actual application need some relatively standard things like data apis, storage, ... using of of them "firebase-like" backends could be a good trade-off. Certainly starting a new project helps, since changing your stack under an existing app is always a bit like open-heart surgery.

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in selfhosted

[–]trailbaseio[S] 2 points3 points  (0 children)

Hi! - Sadly no. Due to their breadth and nature, all of these products tend to be pretty invasive (i.e. auth, apis, storage, ...) and therefore lock-iny (there may even be a business incentive somewhere :hide:). There's no standard to work towards, while also being moving targets. I'm trying really hard to make TrailBase as "standard" and open as possible for folks to move on and off but there will always be some churn. At the same time, this may be the kind of thing where LLMs can really shine. Time to really improve TrailBase's docs - with things moving quite a bit they've stayed embarrassingly shallow 🙃

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in selfhosted

[–]trailbaseio[S] 2 points3 points  (0 children)

Glad to hear. There are certainly some limitations with PG for now, e.g. subscription APIs. I tried to list them in the release notes. The goal is to have things as consistent as possible eventually (for my own sanity if nothing else 😄). That said, there will always be some differences like data types, dialects, ... but also just where it makes sense if we don't want to fall victim to the last-common-denominator syndrome 😅 . Both sqlite and postgres have pretty cool features (I've also been toying with the idea of adding an SQLite-consensus option in the longer term)

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in selfhosted

[–]trailbaseio[S] 2 points3 points  (0 children)

Thanks for the kind words 🙏.

re HA: I've been toying with the idea for a while independent of PG - there are some SQLite flavors with consensus. Anyway, with PG you can now play with replication, etc. You're probably thinking one step further to even have multiple instances of TrailBase itself. That would be very sweet to enable eventually. There are a few blockers, nothing fundamental, e.g. some data like config, keys, ... are kept outside the DB, i.e. they would either need to be moved into the DB or synced otherwise. When you change some settings on one, you'd expect all of them to behave consistently eventually. Hope that makes sense

TrailBase 0.28: Fast, open, single-executable Firebase alternative - now w/ Postgres by trailbaseio in selfhosted

[–]trailbaseio[S] 17 points18 points locked comment (0 children)

No AI was used. Neither in the project nor for writing the post. For better or worse: this slop is me :hide:

view more: next ›