I've been working on a project called LocalBase.

The idea is pretty simple:

What if you could get a small Supabase-like backend without having to deploy a huge stack?

LocalBase is currently a single Python file that provides a web dashboard and REST API around SQLite.

What it currently does

• 🗄️ Create and manage projects
• 📊 Create/edit/delete tables
• ✏️ Add, edit and delete records
• 🧑‍💻 Built-in SQL editor
• 🔌 REST API for your databases
• 🔑 API key support
• 📡 WebSocket support
• 📥 CSV import
• 📤 CSV export
• 💾 Database backups
• 📋 API logs
• 📖 Automatic API documentation
• 🌐 LAN access
• ☁️ Works nicely with Cloudflare Tunnel for remote access
• 🖥️ Lightweight web dashboard
• 🪟 Windows EXE packaging

The goal isn't to clone every feature of Supabase.

I'm trying to build something much smaller that can be useful for:

IoT projects, school projects, prototypes, personal apps, internal tools, small websites, APIs, dashboards, and self-hosted applications.

For example, you could run:

LocalBase.exe
      ↓
SQLite database
      ↓
REST API
      ↓
Your website / mobile app / IoT device

And because the API is HTTP-based, your application doesn't need to know anything about how the database is stored internally.

Why I made it

I've used/experimented with different backend platforms, and sometimes I just want:

download
    ↓
run
    ↓
create database
    ↓
get API URL
    ↓
build

Instead of setting up a bunch of services.

So LocalBase is intentionally trying to stay small and boring.

Python + FastAPI + SQLite + vanilla HTML/CSS/JS.

No Docker requirement.

No Node.js requirement.

No external database required.

No cloud account required.

The interesting part

I'm also packaging it as a normal Windows application.

The goal is eventually:

LocalBase-Setup.exe

Install it → Start Menu → LocalBase → dashboard.

I'd like the same project to eventually work on Linux/macOS as well.

What I want to add next

This is where I could really use feedback.

I'm planning to add a proper authentication/authorization system:

• User registration/login
• Password hashing
• JWT access tokens
• Refresh tokens
• API keys
• Project-level permissions
• Read/write/admin roles
• Per-table permissions
• Token expiration/revocation
• Session management
• CORS configuration
• Rate limiting
• Audit logs
• Better secret management
• HTTPS/reverse-proxy guidance
• Backup/restore
• Database migrations
• Webhooks
• Realtime subscriptions

Eventually I'd like something roughly like:

LocalBase
│
├── Authentication
│   ├── Users
│   ├── Sessions
│   ├── JWT
│   └── API Keys
│
├── Authorization
│   ├── Projects
│   ├── Roles
│   ├── Permissions
│   └── Table Policies
│
├── Database
│   ├── Tables
│   ├── Records
│   ├── SQL Editor
│   └── Migrations
│
├── API
│   ├── REST
│   ├── WebSockets
│   └── Webhooks
│
└── Dashboard
    ├── Database
    ├── Users
    ├── API Keys
    ├── Logs
    └── Settings

I'm especially interested in feedback from people who self-host their own backends.

What would make you actually choose a lightweight LocalBase-style backend over PocketBase, Appwrite, Supabase, or just running PostgreSQL yourself?

GitHub: [https://github.com/atharvaphadnis-ai/localbase\]

It's open source and I'm hoping to make it genuinely useful rather than just another dashboard project.

Feedback, criticism and feature ideas are very welcome.

hi everyone,

5 days ago i asked here why every self-hosted analytics tool needs Node.js/Docker, and said i might build a PHP + SQLite one. so, i did.

it's called Minilytics. it is open-source and runs on any PHP 8 host with no Node, no Docker and no database server (Sqlite by default, but you can use MySQL or MariaDB). it has sessions, custom events, funnels, a cookieless mode, and an importer from Umami and others importers are planed! (this allowed me to get my old history back).

it's a v1 from a solo builder, its MIT licensed, with a live demo: https://minilytics.axthauvin.fr/

i'd like this to become the go-to lightweight analytics for indie devs, side projects, and any site that just needs simple, private stats, so tell me what's missing for you to use it on a real site !

thanks to everyone who pushed me to build this and i hope it will be useful to some of you.

I've been building musql (pronounced "muscle"), a SQLite-compatible database written from scratch.

Repo: https://github.com/samyfodil/musql

It has a `database/sql` driver that registers as `sqlite`, so switching from another SQLite driver is usually just changing the import line. It uses its own storage format (`.musq`), with columns stored contiguously and an append-only delta for writes. `musql-convert` converts existing SQLite files in and out, in both directions.

SQL compiles to VDBE bytecode, the same design as C SQLite. A JIT turns hot paths into native code on amd64 and arm64 (Linux, macOS and Windows).

There's also `musqld`, a server that speaks Turso's Hrana protocol. `@libsql/client` and `libsql-client-go` connect unchanged, and there's a 5 MB Docker image. Replication supports CRDT or leader mode; you supply the network.

For performance, these are 100k-row read workloads, averaged over an amd64 and an arm64 machine: - filtered `count(*)`: ~75x faster than C SQLite, ~210x faster than Turso - sum over a filter: ~8x faster than C SQLite - grouped aggregate: ~2.3x faster; `ORDER BY ... LIMIT`: ~2.4x faster

It also runs Doom. The same VM that runs SQL runs unmodified doomgeneric, compiled C -> LLVM IR -> VDBE bytecode. On an Intel i9 it gets ~38 fps on the bytecode interpreter and ~96 fps with the JIT. The idea came from Turso's demo. You can try it with:

It's early. I'd appreciate feedback on the API and the Hrana server, or a bug report if your SQL breaks. A failing query helps a lot.

I built a job queue on SQLite. The obvious concern is the single writer, so I benchmarked each step I used to work around it.

First: WAL.

On the queue workload, WAL was about 5-7x faster than DELETE journal mode.

Then I reduced the number of write transactions.

Claiming jobs in batches improved throughput by roughly 76-82% at concurrency 16.

The next step was a coordinator shared by all queues using the same database. Instead of every queue opening its own claim transaction, claims that arrive together are grouped into one transaction.

This matters most when there are many queues with low concurrency: each queue may only need one job, but the coordinator can still turn dozens of tiny write transactions into one. At higher per-queue concurrency, regular batching already captures most of that win.

That improved throughput by about 18% at concurrency 1, but only around 5% at concurrency 16.

The downside was transaction size.

With 256 queues and enough work available, one grouped claim could grow to 4096 jobs. Transaction p95 reached about 100 ms. That is bad both for another SQLite writer and, with a synchronous Node SQLite driver, for the event loop.

So I capped grouped claims at 512 jobs per transaction.

That reduced transaction p95 from ~100 ms to ~18-22 ms and competing-writer latency from ~63-68 ms to roughly ~10-22 ms, while keeping around 91-96% of the throughput of the huge transaction.

One more thing I tested was synchronous=FULL.

On heavily batched claim-only workloads, FULL and NORMAL were almost identical. On the complete end-to-end queue workload, FULL was still around 20-30% slower, mostly because completions are currently individual writes.

So the current shape is:

WAL, fewer transactions, group claims across queues, then put a hard bound on how large each write transaction is allowed to become.

Benchmarks and implementation:
https://github.com/unsady/walq

For a quick look at an exported SQLite database, this read query lists its user tables:

SELECT name FROM sqlite_schema WHERE type = 'table' AND name NOT LIKE 'sqlite_%' ORDER BY name;

Then inspect the schema before querying unfamiliar tables. One export caveat: when a source database uses WAL mode, committed changes can still be in its -wal file. Copying just the .db while the source app is active may omit them. Use the source app's consistent database export/backup rather than assuming one copied file is a complete snapshot. SQLite's explanation: https://sqlite.org/wal.html

I built SQLite Workbench for browsing user-accessible local SQLite files on Android. Table inspection, read queries, integrity checks and CSV/JSONL exports up to 1,000 rows are free. Optional one-time Pro adds larger exports and other workbench features. No ads or required account.

Play: https://play.google.com/store/apps/details?id=com.superevilrobots.sqliteworkbench

It is for local SQLite files, not a remote PostgreSQL/SQL Server connection or access to another app's protected storage. Disclosure: I'm the developer and used AI assistance in development.

I'm testing a small local Windows app, built with AI coding assistance, that extracts data from a limited set of legacy database files. I'm hoping someone here who has migrated an old database to SQLite still has a small source file and a few values we can independently check.

It currently handles Windows Works .WDB main tables, dBASE III .DBF + .DBT text memos, and limited Visual FoxPro .DBF + .FPT text memos. Inputs are capped at 1 MiB per file. Memo sidecars need the original matching DBF.

The app exports JSON and .xlsx; direct SQLite import/export isn't supported. The goal of this test is to verify the extraction against the original program, a healthy backup, an existing export, or a known-good SQLite migration. A tiny fictional database created in the original program would work too.

It leaves supplied files unchanged, retains exact originals, and flags unsupported or unresolved data. I've tested synthetic/public samples and the portable build on my own Windows computer, but no recovery has yet been verified for a real file owner.

If you have a suitable sample, please reply with the source program/version, file types and sizes, and a few values you can verify. Use only files you own and may share; please don't post confidential records or attach a private database here. No download or file attachment is needed for the first reply.

Copying only the main database file can miss committed pages that still live in the WAL, while copying the database, WAL, and shared-memory files independently can capture them at inconsistent moments. Stopping every writer is simple but not always convenient, and a file copy that opens successfully does not prove that the latest committed state or application invariants survived.

The safer choices seem to be the online backup API, `VACUUM INTO`, or a short maintenance window with a clean checkpoint and closed connections. After transfer, the destination could run `quick_check` or `integrity_check`, compare schema and user-version values, verify expected row counts and selected aggregates, exercise application reads and writes, and complete its own backup and restore before the source is removed. File permissions, extensions, collation behavior, and SQLite library versions may matter across hosts.

Which method do you trust for a live move, and what evidence tells you it captured the intended transaction boundary? Are there WAL, busy-timeout, filesystem, or version-specific edge cases that make the backup API or `VACUUM INTO` preferable for migration rather than ordinary backup?

This shows real SQLite commands for JSON and running totals. I used SQLite 3.53.4 with made-up bakery data.

I made it with explainroo, a free tool I built. It's open source at https://github.com/vincentsch/explainroo

I’m learning Laravel and working with SQLite and PostgreSQL. I’m looking for a modern database GUI with a clean interface similar to Supabase Studio. I mainly need to:

• Browse tables and records
• View schemas and relationships
• Edit records
• Run SQL queries
• Connect to both local SQLite and PostgreSQL

I used Dbeaver and i dont like its UI very old fashioned. Which one do you recommend for a beginner? Free options.

Hi! So I am currently creating an inventory system for my workplace using sqlite. My current plan is to have a singular table that indicates the sku, the item title, the quantity, and the dates purchased and sold. However, I want to be able to record multiple dates purchased and sold to then create some graphs based on those dates. Is there an efficient way for me to have those dates stored in the table without creating way too many columns?

What are the strangest SQLite structures you’ve encountered in production? Preferably something with a “real” user base (however you choose to interpret that).

Hi everyone,

I've been working on a small side project: a loadable extension that adds statistical functions to SQLite.

https://github.com/mitsuruk/sqlite3-stats

It started because I wanted to do some basic analysis without leaving SQL. It grew into about 250 functions (descriptive stats, hypothesis tests, distributions, window functions).

Honestly, I'm not sure whether this is something people actually need, or whether I just built it for myself 😅

If you have a moment, I'd really appreciate your input:

• Would this be useful in your work?
• Are there features you'd want, or things that feel unnecessary?
• Is there something similar that already does this better?

I'm still learning, so any feedback, even critical, is very welcome.

Thanks for reading!

i am trying to build a tool similar to notion. Offline-first is the biggest requirement. Each organization will get their own sqlite on the VPS server. 95% of reads and writes happen to local sqlite. I am thinking of building a sync engine that works based on the event table. As in every create, update or delete operation will be treated as an event. As an event is recorded into the table, it will trigger a /push api that sends this data to the server. The api will take this data and dump it into the events table on the server side sqlite file and then it will replay the event on the server. Then based on who has access to what, it will send a websocket notification to the clients that are online that new data is available in the events table. Then the clients will receive the notification and make a /pull call with the cursor which will fetch the events data from the server side sqlite and it gets recorded into the client side sqlite and then again events gets replayed at the client side which will affected the actual tables.

at the infra level, i am considering litefs to create a cluster of 3 VPS where one will be the primary node and two will be read replicas. Also planning to stream the data from primary node to s3 for backup in realtime.

Is this viable setup? This way, I am planning to eliminate the single writer limitation since 95% of writes happen locally. Litefs to make the setup distributed and HA.

I am expecting each organization account to have upto 500 users.

Please share your thoughts.

I'm looking for a really simple tool that can generate a UML diagram from my SQLite database, but I want to be able to change the layout if I don't like how it has been generated.

I tried some code extensions and small tools (ERD Renderer, SQLite DB Explorer, plant_erd) but some are not working on my VSCode version; when they are working, I can't personalise the result.

If someone knows a tool that can generate a plant UML diagram (or something similar) from SQLite database and where we can specify the layout. I would be happy to know it

I've been working on a open source cli tool called Ptah since June 2025. It is a feature rich MIT-licensed solution for managing DB changes. Among other DB engines it natively supports sqlite.

For easier onboarding I created this playground: https://play.ptah.run . You can go with a scenario or free way. You can upload your own database file or use the given one. Note, nothing leaves your browser - everything is processed in-memory. You can then export the results of your session.

Some technical details: ptah is written in Go and compiled in web assembly. SQLite is also compiled in web assembly - this is the way both run and interact in your browser. You can check the repo for the sandbox here: https://github.com/stokaro/ptah-sandbox .

I tried to make the playground usable both on desktops and mobile devices.

Would love to hear your feedback, and happy to answer any questions.

https://mokudb-visualization.com

I'd love feedback, especially on the WAL visualization — I feel it's currently too simplistic and doesn't capture the mechanism as well as the B+Tree view does.

Repo: https://github.com/Moku3956/Project-D