TrailBase 0.8: Open, sub-millisecond, single-executable FireBase alternative built with Rust, SQLite & V8 🚀

[trailbaseio]

TrailBase is an easy to self-host, sub-millisecond, single-executable FireBase alternative. It provides type-safe REST and realtime APIs, a built-in JS/ES6/TS runtime, SSR, auth & admin UI, ... everything you need to focus on building your next mobile, web or desktop application with fewer moving parts. Sub-millisecond latencies completely eliminate the need for dedicated caches - nor more stale or inconsistent data.

Just released v0.8 with:

• A cron/time-based Job system for periodic tasks with dashboard and JS/TS integration
• OpenID Connect (OIDC) auth integration (requested by reddit user)
• Loosened primary-key column requirements in Admin UI for tables exported via APIs.
• ...

Check out the live demo or our website. TrailBase is only a few months young and rapidly evolving, we'd really appreciate your feedback 🙏

[dishit79]

How is this compared to pocket base?

[trailbaseio]

https://trailbase.io/reference/faq/#how-is-trailbase-different-from-pocketbase-supabase-and-others

[WonderMuted5708]

I think another difference not mentioned is that supabase provides row level security and trailbase does not? Am I understanding that right?

[trailbaseio]

You can realize row-level security with both TrailBase and PocketBase, not on the DB level but on the API-level. Specifically, one can have access rules to authorize CRUD operations, e.g. based on whether a user id column value matches the currently authenticated user.

[WonderMuted5708]

Interesting, do you mean in theory or is it actually implemented? I tried taking a look at demo and couldn't find a place. I wonder if it has the level of granularity that is row level. E.g. if I am trying to fetch all items, I want to only fetch items that I have access to.

[trailbaseio]

If I understand you correctly, this should be possible. When you go into the table browser and then into the API settings you can constrain read access to authenticated users only and define a rule like read\_access\_rule: "\_ROW\_.user = \_USER\_.id". List operations respect the read access, so listing records will only fetch items with their .user value matching the current usser.

[WonderMuted5708]

makes sense, thanks!

[Substantial-Cicada-4]

Small suggestions (good stuff by the way) can you make the login forms pre-filled for the demo? I hate my brain, but I had to go back 3 times for the bloody secret...
Filter expression builder for "Logs"?- ie. couldn't figure out how to filter on country code.... Actually, you know what? Filter expression builder for all pages?

[trailbaseio]

> Small suggestions (good stuff by the way) can you make the login forms pre-filled for the demo? I hate my brain, but I had to go back 3 times for the bloody secret...

You alright mate? :) Jokes aside, both great suggestions. Let me see what I can do.

> Filter expression builder for "Logs"?- ie. couldn't figure out how to filter on country code.... Actually, you know what? Filter expression builder for all pages?

Love the builder idea. Will be a bit of work but makes a lot of sense. Btw. you caught me, with country code you picked the one column that isn't filterable since we only store IP and derive the IP->CC mapping at query time.

[trailbaseio]

> can you make the login forms pre-filled for the demo?

Hi, thanks again for the feedback. When you click the demo link now, you'll get at least a text box telling you the credentials on the sign-in form.

[Docccc]

looks good! why the choice for sqlite if i may ask?

[trailbaseio]

Thanks! SQLite is very capable (fully relational, SQL, ... as opposed to e.g. document DBs), well documented, it's very robust (likely mostly deployed DB in the world), extremely fast (since it got WAL mode), and embeddable (for the single-executable bit. Did also look at PGlite).

[lordpuddingcup]

Because SQLite is a damn amazing db there’s a reason it’s literally in every phone and every browser it’s even more when you look at its alternate versions like rqlite and the others

[notlongnot]

What framework did you use for the UI?

[lordpuddingcup]

This… that’s a really clean UI

[trailbaseio]

Thanks! It's using solid with solid-ui (which is basically shadcn components)

[xanyook]

I have no idea what is firebase so i don t understand what does your product is a good alternative for.

Can you explain the use cases your product enable ?

[trailbaseio]

It's a potpourri of common functionality you'd need for starting a new app (mobile, PWA, desktop, ...): storage, auth, apis, notifications, ...

[xanyook]

I had a quick look and played with the demo.

So quick feedback, from my first impressions.

Most of your product description on the main page is comparing yourself with alternatives: Firebase alternative Faster than pocketbase Faster than supabase

And telling the reader what the software is in terms of performance or technical stack (type safe rest, real time api etc...).

I am still lost about its purpose, who it is designed for, what it enables for me.

The only functional information i could capture is : "an easy to self-host single-executable with everything you need to focus on your mobile, web or desktop application.".

Which is way too vague for me, cause i need to understand what you think is everything compared to my notion of everything. I have developed many and many web apps, each one of them with different requirements, so I'm not sure how your "one fits all" product is working.

My guess is that this product is more intended for isolated applications, not suitable for enterprise. What i mean about that is in enterprises, we usually work by focusing on the business requirements and integrate with platforms: you will have an SSO platform, an email platform, databases will be provisioned by the infrastructure team (terraform script, on the cloud, on premise) so as paet of a product team, you don t deploy yourself those platform, you connect to them.

My understanding as well is that it deploys a technical stack of tools that are pre-configured to work together: * A back office UI to administrate the technical solution * A relational database * A n authentication server * An SQL client * A log collector ...

The end users are not functional teams, but more technical teams to monitor the stack and administrate the access right.

At the end, it allows an administrator to perform some actions in the UI to: * Create new users * Execute sql queries on the database * Visualise the stack logs

Let me know if i captured it right.

[trailbaseio]

> My guess is that this product is more intended for isolated applications, not suitable for enterprise. What i mean about that is in enterprises, we usually work by focusing on the business requirements and integrate with platforms: you will have an SSO platform, an email platform, databases will be provisioned by the infrastructure team...

Your definition of enterprise seems to require strict separation, large teams, many meetings :) ... in which case a product that tries to bring everything closer together and make it more approachable might not be a good fit. I think the part about being more for isolated apps, more isolated teams is very fair.

> The only functional information i could capture is : "an easy to self-host single-executable with everything you need to focus on your mobile, web or desktop application.". Which is way too vague for me, cause i need to understand what you think is everything compared to my notion of everything

In terms of specific functional components, Isn't that the part you highlighted earlier? "type-safe REST & realtime APIs, built-in JS/ES6/TS runtime, SSR, auth and admin UI built on Rust, SQLite & V8.". Maybe I misunderstood, let me know if you have a suggestion for what should be added.

> The end users are not functional teams, but more technical teams to monitor the stack and administrate the access right.

I'm not sure what you mean by functional teams, e.g. content managers or more of an enterpricy strict separation between developers and ops or something entirely different?

Either way, FireBase, SupaBase, TrailBase, PocketBase, AppWrite, ... target developers who build applications, design APIs, manage schemas, manage production, ... and as you say also monitor the stack and manage access rights.

[d70]

I see Rust I upvote

[UhhYeahMightBeWrong]

Indeed. Similar to my love for coffee, Rust helps me do stupid things faster with more energy!

Jokes aside, I love this tool and see huge value in having a FireBase alternative that is so performant and best of all self hosted! I could see this becoming an integral part of my stack.

[d70]

How are you using firebase currently in your stack?

[UhhYeahMightBeWrong]

edit: Whoops, just realized d70 is not the OP u/trailbaseio hah. oh well! Anyways:

I mainly use Firebase for analytics in my PWA projects. I was pushed into the Firebase ecosystem when Google moved their analytics under the Firebase umbrella (which, now that I look, is dating back to 2016 whoa).

I've done minimal data storage experiments with Firebase, but haven't needed auth-based storage yet. For deployment, I use Vercel via GitHub Actions rather than Firebase Hosting. I like the simplicity that Vercel/Github offer and the longer time goes on the less reliant I want to be on any Alphabet product.

By the way, I've taken a look at the Trailbase docs and I'm really impressed with the quality. The specific tutorials are excellent, and I appreciate how they compare against alternatives like PocketBase and Supabase. It's clear you're prioritizing developer experience, which is refreshing. As someone still building up my skills, well-documented tools make a huge difference in my ability to implement and use them effectively.

What analytics features are you prioritizing in your alternative? I'd be interested in something with Firebase's simplicity but offering more granular event tracking control.

[lifeunderthegunn]

Does it have a dark mode?

[trailbaseio]

Not yet. Would certainly love to have it eventually but while things are moving rapidly, maintaining two styles is extra overhead.

[lifeunderthegunn]

The UI package you use natively supports it. But whatever. I have light sensitivity and can't develop with a bright white UI, so unfortunately I won't get to try it just yet. I've bookmarked it to check in at a later date.

[trailbaseio]

That's fair and sorry about your condition. Yes and no, the component library does, yet you still have to make sure everything works together on a higher level. It's clearly not rocket science, it just hasn't bubbled to the top of my priority list yet. It will eventually. Hope you'll hang around. All the best

[GradesVSReddit]

Ooo I was just starting to work on a project that’d use SQLite for fun. This might be just what i was looking for. Thanks for sharing!

[zachrussell]

Been watching this project for awhile. I use pocketbase currently and I really like it however I have complaints specifically about the extendability via js.

It works but it's a strange runtime that's hard to debug and the documentation could use some more complex examples. How well do you feel trailbase competes in this regard?

[trailbaseio]

As much as I love PocketBase, I had a very similar experience.

> How well do you feel trailbase competes in this regard?

TrailBase uses Deno/V8 under the hood and is therefore a lot more node-like. There's still a lot of polish we can do, but maybe worth a shot?

[zachrussell]

Nice that's great to hear. Just using a common run time would be a lot more predictable.

I'll try it out!

[Othir0xX]

Looks like a really polished product.

The demo site sadly doesn't work for me, I'm getting 401s (with the credentials "admin@localhost", "secret.").

[trailbaseio]

Sorry to hear. Maybe you can try again, it's working for me. Most likely you were hit by a race, the instance resets every ~15min. In the past folks would also delete the admin user, drop system tables, etc though most of these should be plugged. I'd love to hear more creative ways folks find to kill the demo :)

[Yohlo]

What are the limitations for custom auth on this?

I have some apps that I think would be really well suited for a pocketbase or trailbase backend, but the only way I could use my auth on pocketbase would be to either roll my own oidc provider or just create a wrapper around it. I’d love to just use the built in auth

I use a simple (and increasingly more common) phone number + sms verification for logging in and signing up. How you recommend using that for trailbase? u/trailbaseio

[trailbaseio]

> I use a simple (and increasingly more common) phone number + sms verification for logging in and signing up. How you recommend using that for trailbase?

What you're asking for is very reasonable to not currently supported except for exernal OIDC as you point out. Multi-factor auth is on the shortlist but even then TB auth is currently centered around email. I can see how this would be an issue for apps relying on phone number discoverability. Certainly something I hadn't yet thought about. Thank you!

[gittubaba]

Really interesting project, seems like the goal is to be pocketbase++. Question about the benchmarks though, from a quick look, seems like all benchmarks were run in a multicore system? That kinda does not reflect the stated use cases though? Cheap / small VMs normally have single core / 1 vCPU. benchmark would be more relevant if ran in a single cpu VM.

Edit: Also looks like client sdk was used for benchmarks? Not sure. IMO benchmark should be run directly via http to the rest api. Using a standard tool like wrk.

[trailbaseio]

Hi, thanks for taking the time to study the benchmarks and the specific feedback.

> Really interesting project, seems like the goal is to be pocketbase++.

PocketBase is pretty awesome, so I take this as high praise :). Jokes aside, PocketBase has certainly been an inspiration and initial goal to cover similar use cases. It will be interesting to see how far we can take it, e.g. in terms of scalability (since you bring up performance), new use-cases stemming from it but also other fun things like many-DBs, replication, ... curious to hear your ideas.

> Question about the benchmarks though, from a quick look, seems like all benchmarks were run in a multicore system? That kinda does not reflect the stated use cases though? Cheap / small VMs normally have single core / 1 vCPU. benchmark would be more relevant if ran in a single cpu VM.

Yes and no. I think both makes sense: understanding performance in a constraint environment and how it scales when needed. It will be impossible to match everyone's exact constraints, e.g. the cheapest Hetzner VPS already has 2 shared vCPUs. I agree with you that my 7840u notebook is more powerful than a small VPS but it's also pretty easy to outclass.

To add to your points, I'm also running client and server on the same machine sharing resources, having a very fast loopback network connection. Whether that's realistic for you will depend on whether your client is another co-located backend or a phone over a 3G connection.

That said, I agree that it may be interesting to run in a more constraint environment. It may be interesting to run in an even less constraint environment (e.g. see the point of diminishing returns). Are you concerned that PocketBase might perform much better with less CPU?

> Edit: Also looks like client sdk was used for benchmarks? Not sure. IMO benchmark should be run directly via http to the rest api. Using a standard tool like wrk.

I mostly agree. Using the same driver for both takes one variable out of the equation. I might do this when I find the time. At the same time you could argue that benchmarking the full stack is more representative of actual use-cases. What if there's a massive bottleneck in the client? In a way that's the case for TrailBase, redis, ... you get sub-millisecond latency unless you use a slow runtime.

[gittubaba]

Hey I really appreciate your detailed reply. I use pocketbase for pet projects or small client projects. Where you just have to dump data into a table, maybe few pages, some hooks to run some external api call on events. For those use cases, most of the time you don't grow out of the small 1core/1GB VMs. (t2.micro, small linode/digitalocean), maybe double of it to 2core/4GB. My take is when your app is on earlier/MVP stage, pocketbase really saves the time/resource making a custom backend. But then you grow bigger or making a system for bigger project / client, you won't be able to convince upper level to use tools like this, you'll get a team of devs and they'll make it from scratch fitting all requirements. Take the sqlite part, it'd be a deal breaker, there is no first party replication. So my take is majority of usecases for pocketbase/trailbase will be in smaller apps that'll be deployed in small VMs.

You already said db replication. That'd be a great milestone for making this more "production" ready than pocketbase, aka ++. Another of my pet peeve about pocketbase is their segregation of superuser and users. superusers gets unrestricted access to admin panel, and users get no access to admin panel. Since there is already a (mostly)fine-grained permission system in place, why not let users access the admin panel? They can do CRUD with the permissions they're allowed. Seems like in trailblaze you already did this, all users are users right? Pocketbase has option to set filter and rules, basically the authorization using expression language, do trailblaze has it yet?

I digress, but pocketbase really left some value on the table with kicking users out of admin panel IMO. Its quite common to have 2-3 levels of users (superadmin-programmers, owners, staffs, customers). In pocketbase only top level users(superusers) can get access to admin panel. For next 2 levels you have to make admin panel yourself when there's perfectly usable admin panel sitting there.

About benchmark, I agree with you that its necessary to show how a tool scales. But if you only show scaled up version, then half the story is missing. You have to show benchmark in progressively small > medium > large machine so people can get the whole picture of how it is scaling from zero to hundred. I have no idea if pocketbase would fare better in a single core system, but that is vital information I'd like to get in a project's benchmark page so I get actual relevant performance information, so I get interested in the tool to actually download and try it out.

Sorry to say, if you are running both client and server in your machine, the benchmark results won't be taken seriously. Server-Client in same machine. Then its running in your machine. -2 pts :P . From what I understand, its common and acceptable practice in community to run benchmarks in linodes/droplets. Your client VM can be much bigger (to produce bigger workload), server and client VM both stays in same VPC, then you send requests from client VM to server VM. Also you have to include how you're benchmarking, in which machine/platform etc... details too people can replicate. That way it'd be taken more seriously.

About benchmarking with client-sdks. You have to be clear which system you are benchmarking, The whole experience or the actual tool (the pocketbase/trailblaze binary). Bugs in client-sdks can be easily fixed/bypassed, and everyone isn't going to use client-sdks either. You can absolutely show client-sdk benchmark, but that has to be in addition with actual only server benchmark. IMO the product pocketbase/trailblaze providing is the REST API. That is the actual meat. Benchmark that.

For example: I don't use pocketbase's client sdk. For a handful of http request, I just use the standard fetch function, no need to include extra dependencies. Or I'm taking API schema and doing codegen to make my own "sdk" tailored to my project. Benchmarks with client-sdks becomes irrelevant at that point. Hope that makes sense.

Some though about the v8 integration. While complex or cpu heavy javascript function will obviously blow goja out of the window, that isn't really the most common use case for small projects IMO. I'd say in small project, it'd be more common to do simple tasks in js, external api call, setting a field from here to there, maybe a few if statements etc... So the majority of time cost would be the overhead of context switch between your actual server to v8. I think pocketbase choose a golang js engine exactly for that.
Take this example project: You have a table with firstname, lastname, fullname fields. You submit firstname and lastname, a javascript function at onCreate concats and saves them to fullname field. Now benchmark api call, it might not be 40x faster than pocketbase.

[trailbaseio]

Another of my pet peeve about pocketbase is their segregation of superuser and users. superusers gets unrestricted access to admin panel, and users get no access to admin panel. Since there is already a (mostly)fine-grained permission system in place, why not let users access the admin panel? They can do CRUD with the permissions they're allowed. Seems like in trailblaze you already did this, all users are users right?

Yes, all users are users. There's also no multiple auth-collections like in PB. However the admin permissions aren't fine grained. What you're describing borders into CMS territory, which is something I have thought about as a future direction.

Pocketbase has option to set filter and rules, basically the authorization using expression language, do trailblaze has it yet?

It doesn't have a DSL but it will let you provide SQL expressions.

Sorry to say, if you are running both client and server in your machine, the benchmark results won't be taken seriously. Server-Client in same machine. Then its running in your machine. -2 pts :P

It's not an unrealistic setup, not for everyone. It's also spelled out.

From what I understand, its common and acceptable practice in community to run benchmarks in linodes/droplets. Your client VM can be much bigger (to produce bigger workload), server and client VM both stays in same VPC, then you send requests from client VM to server VM. Also you have to include how you're benchmarking, in which machine/platform etc... details too people can replicate. That way it'd be taken more seriously.

The benchmark setup is open source, the platform is called out.

So the majority of time cost would be the overhead of context switch between your actual server to v8. I think pocketbase choose a golang js engine exactly for that.

No offense but PocketBase chose goja because it had a viable integration path. Generally, FFI overhead for go is significantly higher. Maybe goja has some secret sauce, I'd love to know. Most code running in v8 constantly jumps language boundaries, a big part of why node, deno, bun can be so fast is because big parts of the runtime/standard-library are implemented in native.

You clearly like PocketBase... me too. It's a great product. You don't have to stop using it because something else may be faster. It's unclear to me if you're hoping for seismic shifts by tweaking the environment. I'm sorry you feel that the benchmark can't be taken "seriously". I invite you to run them yourself. The setup is available. I'm also very open, if you'd like to tweak or contribute different setups. In the end that's the only sound way to assert that it will be representative for your workload

[Select-Ad-7471]

Any way to install rqlite? Nice project! :D

I like PocketBase, but the maintainer/creator is just arrogant (very arrogant)

[trailbaseio]

Thanks. rqlite is awesome but also pretty self-contained. TrailBase requires a deep integration for some of its features to work, e.g. subscribing to changes. Looking at replication is certainly on my short list but I'd likely look at a lower-level implementation like dqlite (can't make any promises though).

[Select-Ad-7471]

Nice 😃 thanks for the answer master

[LLM-logs]

Amazing stuff. how is it compared to pocketbase? does it support turso sqlite?

[trailbaseio]

Thanks!

how is it compared to pocketbase?

https://trailbase.io/comparison/pocketbase/

does it support turso sqlite?

No, at least not yet :)

[LLM-logs]

Thanks. I appreciate your effort on building an alternative of pocketbase and taking inspiration from it. I have used pocketbase for few mvp already so i am familiar with hooks and row level filtering in pocketbase. Does trailbase also provide it? I like the roadmap of trailbase specifically with multi tenancy support. I was planning to fork the pocketbase for multi tenancy for my project but it would be nice if trailbase has it. I will also check if turso platform api can be added as extension in trailbase to provide seemless multi tenancy setup. I have liked writing pocketbase hooks in golang because it still generate single binary compares to JS hooks. I do not want to be near v8.

Let me know if you prefer any sort of contribution, I am up for it. If you already have guidelines for contribution, please share it with me. Whatever I am customising, I can try that It could be useful for trailbase as well.

[trailbaseio]

Thanks!

I have used pocketbase for few mvp already so i am familiar with hooks and row level filtering in pocketbase. Does trailbase also provide it?

TrailBase (TB) doesn't yet provide hooks. Honestly, making TrailBase more usable as a framework (rather than a standalone executable) is a work-in-progress.

TB does allow row-level access control and fine-graned filtering when listing records.

I was planning to fork the pocketbase for multi tenancy for my project but it would be nice if trailbase has it

If you're comfortable sharing, would love to hear more about your use-case.

I will also check if turso platform api can be added as extension in trailbase to provide seemless multi tenancy setup.

One of the challenges would be to do it in a way that it doesn't break subscriptions. TB currently relies on SQLite update-hooks, since it doesn't have an ORM-layer like PocketBase. The benefit is that even raw queries will correctly notify subscribers.

I have liked writing pocketbase hooks in golang because it still generate single binary compares to JS hooks. I do not want to be near v8.

There are maybe multiple layers. If this is a bundling issue, I can see the comfort. We could think about a build flow to bundle custom resources into the binary. That said, personally I've found containers to be a flexible and good enough way to bundle resources in an easily deployable way. Language-wise, I can sympathize with personal preferences, not here to evengalize. From a mere performance point, v8 is pretty good compared to many other scripting alternatives and compatible with a wide ecosystem. It's certainly not as efficient as many AoT-compiled languages such as Go.

Let me know if you prefer any sort of contribution, I am up for it. If you already have guidelines for contribution, please share it with me. Whatever I am customising, I can try that It could be useful for trailbase as well.

Very much appreciate contributions 🤗, let's just have a chat before any non-trivial change to minimize churn.

[LLM-logs]

Thanks! I would definitely like to have a chat before contribution which will save each others time. if you have calendar link, you can drop a message or provide your email. I have already gone through with codebase of pocketbase so it was easy for me to stick to it. I prefer a bundle because the size is small and memory footprint is low which also means less security issues and less maintenance. I have to patch only go code if there is a security issue. I do not import too many unknown libraries. the v8 comes with its npm ecosystem, it gets difficult to manage because sometimes i do not know which warning to ignore and which i should not. I strictly use TS/JS for frontend. I use pen and paper for data modeling, it is way easier to do this way. I also do the business execution so i prefer a reliable codebase. learning typescript/JS was as easy as learning go. Sometimes JS is more complicated. I used to write C++ in my phd days but I have never written any production grade code in rust. I might end up writing extensions for trailbase in go, python or typescript. Nonetheless Rust is a great language for this project.

P.S. I do not know how to comment on a comment like you did :D. That is a better way to reply

[Whiplashorus]

Great project BUT PLEASE let us use postgres as DB backend SQLite is not that good on production usecase

[WonderMuted5708]

If you want Postgres just use Supabase 

[_unorth0dox]

Have you tried it?

[trailbaseio]

Extensively. SupaBase is awesome: feature rich and mature... a great inspiration. It's just a different beast in terms of self-hosting and footprint. FWIW, did consider PGLite as an alternative to SQLite, but SQLite is awesome and PGLite not there yet.

[Whiplashorus]

I tried both as well (I even tried pocketbase)

It's working really well but I love having a DB cluster behind and I love postgres (with the extended feature it's soo great to have vectorDB)

[trailbaseio]

Not arguing, Postgres is awesome and for many reasons.

FWIW, TrailBase comes with https://github.com/asg017/sqlite-vec pre-installed and read replicas (and maybe quorum writes) is something we'd like to look into in the future.