Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Have you used PocketBase (self-hosted BaaS)?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Have you used PocketBase (self-hosted BaaS)?

AXYZEAXYZE Member
edited March 2023 in General

https://pocketbase.io/
Pocketbase is a Backend-as-a-Service app that will take care of:

  • Database (SQLite in WAL mode)
  • Auth
  • File storage
  • Dashboard to manage all these things

So basically you can create web app in framework like Nuxt.js and don't any write your own backend in Express/Fastify/etc. PocketBase is 100% free, no docker, just single binary file that is very light on resources (10MB RAM usage on start).

I wan't to use it for my next project (video sharing platform) instead of Supabase/Firebase and I'm curious, did anyone use PocketBase and could share his opinion?

Dropping depedency on external services and just setting up simple failover with real-time DB replication ( https://litestream.io/ ) seems like very stable & cheap idea, that would work perfectly on low end VPSes with like 512MB ram and app development would be a lot faster.

Comments

  • Looks very cool. Never tried it though.

    Thanked by 1AXYZE
  • nick_nick_ Member

    Interesting! Thanks for sharing it.

    Thanked by 1AXYZE
  • @AXYZE said: no docker, just single binary file that is very light on resources (10MB RAM usage on start)

    Worth trying just because of this.

    Thanked by 1AXYZE
  • emghemgh Member

    I like it, played around with it a little, but Javascript is hard for me to grasp as a newbie.

    In my current project, I wanted to use Python as a backend, but I wanted a static frontend that's not cached dynamic PHP.

    I ended using doing 50/50, back-end is Python & MariaDB and front-end is Next.js with https://www.prisma.io/. Has been great so far.

    For anyone considering this: Do evaluate whether PocketBase or Supabase is best for your use-case, even Supabase can be self-hosted, though not as lowend of course.

    Thanked by 1AXYZE
  • AXYZEAXYZE Member
    edited March 2023

    @emgh said:
    I like it, played around with it a little, but Javascript is hard for me to grasp as a newbie.

    In my current project, I wanted to use Python as a backend, but I wanted a static frontend that's not cached dynamic PHP.

    I ended using doing 50/50, back-end is Python & MariaDB and front-end is Next.js with https://www.prisma.io/. Has been great so far.

    For anyone considering this: Do evaluate whether PocketBase or Supabase is best for your use-case, even Supabase can be self-hosted, though not as lowend of course.

    Selfhosted Supabase is way harder to setup (you need couple of containers), less efficient on low end hardware, althrough its a lot more commonly used so its surely production ready.

    I want to build new VoD platform for my friend because Wordpress+Woocommerce is causing too much problems, 30 different plugins, everything is just at random places in dashboard and pages are heavy.
    PocketBase seems like a great thing - backend does everything it is supposed to do and I can just focus on making frontend.
    And in terms of frontend I'll use nuxt.js because it is the best fullstack framework hands down. Documentation is kinda bad, but feature and speed wise nothing touches it. Maybe SvelveKit comes close, but I didnt touched it a while so Im not sure what progress they made.

  • quanhua92quanhua92 Member
    edited March 2023

    Between Pocketbase, Supabase and Firebase, I prefer Pocketbase for the single binary deployment. Self hosted supabase contains so much components. It is possible but not as easy as Pocketbase.
    I don't like that Pocketbase is using SQLite. No built-in replication, full text search or high availability.

    My final choice is to using PostgreSQL directly. So, I have all the stable options to extend the system in the future without paying too much at front. For example, pgbouncer for connection pooling, patroni for automated failover and read on replica. You can also create stored procedure (postgresql functions) to handle the complex query directly in the database.

    If you don't want to write the backend code, I think that using the PostgREST for the API between your frontend & database is also a good choice. PostgREST is also used in Supabase. So basically, deploy a very simplify version of Supabase that contains only PostgreSQL and PostgREST.

    I don't know if it is possible to use Nuxt.js to build api routes. But you can easily use Next.js or SvelteKit to write the backend code without using any Express.js code.

    The setup is:
    1. PostgreSQL + PostgREST on a VPS
    2. Next.js / SvelteKit on edge servers (Vercel, Netlify or Cloudflare). API routes are here too.
    3. Complex queries go to stored procedure in PostgreSQL

  • tjntjn Member
    edited March 2023

    Pocketbase looks really cool actually.
    It's a shame it's on SQLite or I would seriously consider using it for a project I'm working on.

    Although not the same but similar, check out https://strapi.io/ and https://directus.io/

  • raindog308raindog308 Administrator, Veteran

    https://pocketbase.io/faq/

    "Even without optimizations, PocketBase can easily serve 10 000+ concurrent and persistent realtime connections on a cheap $6 VPS (Hetzner 2vCPU, 4GB RAM)."

    "For majority of the queries SQLite (in WAL mode) outperforms traditional databases like MySQL, MariaDB or PostgreSQL (especially for read operations). Additionally, a great companion app when you need SQLite replicas is Litestream."

  • tjntjn Member

    @raindog308 said: "Even without optimizations, PocketBase can easily serve 10 000+ concurrent and persistent realtime connections on a cheap $6 VPS (Hetzner 2vCPU, 4GB RAM)."

    That's actually nuts.

    I guess I don't know enough about SQLite, why don't more projects utilise it?

  • @tjn said:

    @raindog308 said: "Even without optimizations, PocketBase can easily serve 10 000+ concurrent and persistent realtime connections on a cheap $6 VPS (Hetzner 2vCPU, 4GB RAM)."

    That's actually nuts.

    I guess I don't know enough about SQLite, why don't more projects utilise it?

    "Because it is not a real sql, hurr durr!"

    People are stupid, they use mariadb or mysql just because everyone else does. I'm not saying they are bad products, but there are alternatives that in many situations would be a much better choice.

    SQLite is an awesome database with simply amazing performance if used correctly. It has some limitations when it comes to concurrent writes, but when it comes to reading or writes in WAL mode it simply kicks ass.
    I often wonder why things like websites which are basically just read operations does not use SQLite more often, it would probably increase performance by magnitudes and make installation and maintenance so much easier.

  • raindog308raindog308 Administrator, Veteran

    @rcy026 said: "Because it is not a real sql, hurr durr!"

    @tjn said: why don't more projects utilise it?

    People want to be able to grumble.

    They refuse to whip themselves.

    They get tired sometimes.

    They like wine.

    All of these are behaviors violate the official SQLite Code of Ethics.

  • @tjn said: I guess I don't know enough about SQLite, why don't more projects utilise it?

    Premature scaling. See https://www.reddit.com/r/ProgrammerHumor/comments/wr6zfs/kubernetes/

  • Where you will write the business logic? > @tjn said:

    @raindog308 said: "Even without optimizations, PocketBase can easily serve 10 000+ concurrent and persistent realtime connections on a cheap $6 VPS (Hetzner 2vCPU, 4GB RAM)."

    That's actually nuts.

    I guess I don't know enough about SQLite, why don't more projects utilise it?

    Because it was not meant for that, it was initially meant for local storage in web apps, usually people prefer and full featured db where you can normalize the records and use complex querying by joining several records, it will be hard to use and will be hard to scale with large record sets.
    Another big issue is with multiuser data management and concurrency. And biggest probably is the lack of SP support.

Sign In or Register to comment.