DEV Community: Muhammad Moiz

Supabase vs Firebase for Startups: An Honest Comparison

Muhammad Moiz — Fri, 30 Oct 2026 06:23:45 +0000

Supabase vs Firebase comes down to one question: do you want a relational Postgres database with SQL, or a document database that syncs to clients with almost no setup? For most SaaS products with users, teams, billing and reports, Supabase is the safer long-term default. Firebase still wins for real-time, mobile-first apps where you want Google to run everything and your data is shaped like documents.

I've shipped production work on Firebase (Timegram, a time-tracking SaaS I built, runs on it) and I regularly work on Supabase apps, many of them generated by AI builders like Lovable. Below is how the two compare on the things that actually hurt later: data model, security, pricing, lock-in and hiring.

What is the difference between Supabase and Firebase?

Both are "backend as a service" platforms. You get a database, authentication, file storage, server functions and real-time updates without running your own servers. The difference is what sits in the middle.

Supabase is built on Postgres. Its docs describe each project as a full Postgres database rather than an abstraction over one, and Auth, Storage, Realtime and Edge Functions all hang off that database. You write SQL, use foreign keys and joins, and can add Postgres extensions such as pgvector for AI embeddings, PostGIS for maps and pg_cron for scheduled jobs.
Firebase is built around Cloud Firestore, a NoSQL document database from Google. Data lives in collections of documents, clients read and write directly through the SDK, and access is controlled by Firebase Security Rules. It plugs into the rest of Google Cloud (Cloud Functions, Cloud Storage, Analytics, Crashlytics, Cloud Messaging).

Neither is "better" in general. They suit different shapes of data and different teams.

Supabase vs Firebase at a glance

	Supabase	Firebase
Database	Postgres (relational, SQL)	Firestore (NoSQL documents)
Queries	Joins, aggregates, views, full SQL	Simple queries per collection; joins done in app code
Access control	Postgres Row Level Security policies	Firebase Security Rules
Pricing model	Plan fee plus usage (storage, egress, MAU)	Pay per document read, write and delete
Free tier	2 active projects, paused after a week of inactivity	Daily free quota on reads, writes and storage
Self-hosting	Possible (open source)	No
Best fit	SaaS, dashboards, B2B, reporting, AI features	Mobile apps, chat, live collaboration, quick prototypes

Supabase vs Firebase pricing: what will you actually pay?

I checked both pricing pages in October 2026. Prices change, so confirm before you budget.

Supabase pricing

Supabase uses plans with included usage:

Free: $0. 500 MB database, 50,000 monthly active users, 5 GB egress, 1 GB file storage, 500,000 Edge Function invocations. You get two active projects, and free projects are paused after one week of inactivity.
Pro: from $25 a month. 8 GB database per project, 100,000 MAU, 250 GB egress, 100 GB file storage, 2 million Edge Function invocations, plus $10 of compute credits. Projects are never paused.
Overages on Pro: $0.125 per GB of database, $0.00325 per extra MAU, $0.09 per GB of egress, $0.0213 per GB of file storage.
Team: from $599 a month. Enterprise: custom.

A useful detail: the Pro plan has a spend cap switched on by default, so you won't get a surprise bill unless you turn the cap off.

Firebase (Firestore) pricing

Firestore charges per operation, not per plan. Google's Firestore pricing page lists a daily free quota of 1 GiB of stored data, 50,000 document reads, 20,000 writes and 20,000 deletes, plus 10 GiB of outbound transfer a month. Above that, in the Iowa (us-central1) location, you pay $0.03 per 100,000 reads, $0.09 per 100,000 writes and $0.01 per 100,000 deletes. Other regions are priced differently.

For sign-in, Google Cloud's Identity Platform pricing page lists email, phone, anonymous and social sign-ins as free up to 50,000 MAU, then $0.0055 per MAU up to 100,000. SAML and OpenID Connect (enterprise single sign-on) are free for only 50 MAU, then $0.015 per MAU. SMS for phone login is billed separately.

Which one is more affordable?

It depends on how your app reads data, not just how many users you have.

Firestore bills every document a query returns. A dashboard that loads 200 documents for every page view costs 200 reads each time. Listeners that re-run on every change add up fast. Badly structured Firestore apps are where surprise bills come from.
Supabase bills mostly for storage, egress and compute. A heavy SQL query costs CPU time, not per row returned, so read-heavy dashboards and reports are usually more predictable on a fixed plan.
For a small app with light traffic, both can stay free or close to it for a long time. Just remember the Supabase free plan pauses idle projects, which is fine for prototypes but not for a live product.

Is Supabase or Firebase better for a SaaS startup?

Ask what your data looks like six months from now.

A typical SaaS has organisations, users, roles, projects, invoices, subscriptions and audit logs, all linked to each other. That is relational data. In Postgres you model it with tables and foreign keys, and a report like "hours logged per client per month, grouped by team" is one SQL query. In Firestore you either duplicate data across documents so each screen can read it in one go, or you fetch several collections and join them in your code. Both work, but duplication means keeping copies in sync, and that is where bugs creep in.

Here is the same question asked both ways. In Supabase:

select c.name, sum(t.minutes) / 60.0 as hours
from time_entries t
join projects p on p.id = t.project_id
join clients c on c.id = p.client_id
where t.org_id = 'org_123'
  and t.started_at >= date_trunc('month', now())
group by c.name
order by hours desc;

In Firestore you would usually keep a running total on each client document and update it every time an entry is written, often from a Cloud Function:

// Illustrative: keep a per-client monthly total in sync on every new entry
export const onEntryCreated = onDocumentCreated(
  "orgs/{orgId}/entries/{entryId}",
  async (event) => {
    const entry = event.data?.data();
    if (!entry) return;
    const month = entry.startedAt.toDate().toISOString().slice(0, 7);
    const ref = db.doc(`orgs/${event.params.orgId}/clientTotals/${entry.clientId}_${month}`);
    await ref.set({ minutes: FieldValue.increment(entry.minutes) }, { merge: true });
  }
);

The Firestore version is fast and cheap to read, but you now have to handle edits, deletes and back-filling old data yourself. Every new report means another pre-computed total.

My rule of thumb:

Pick Supabase if your product is a B2B SaaS, has reporting or admin screens, needs complex permissions, or will add AI search with embeddings.
Pick Firebase if you're building a mobile-first or chat-style app, need offline sync on phones out of the box, already use Google Cloud, or your data really is a set of independent documents (user profiles, messages, feeds).

If you're still scoping your first version, this decision belongs in the planning stage of an MVP build, not halfway through development.

Supabase vs Firebase security: where do apps go wrong?

Both platforms let the browser or mobile app talk to the database directly. That's what makes them fast to build with, and it's also why security has to be done right on day one.

Supabase relies on Postgres Row Level Security (RLS). If a table is exposed and RLS is off, or the policies are too loose, anyone with your public anon key can read the data. This is the most common problem I find in apps built with Lovable and other AI tools. I wrote a full guide on it: Supabase RLS explained.
Firebase relies on Security Rules. The classic mistake is shipping with test-mode rules that allow all reads and writes, or rules that check a user is signed in but not that they own the document.

Check this before launch

Whichever you pick, test your access rules with a second, non-admin account. Try to read and change another user's data. If you can, so can anyone else.

Lock-in and switching later

Supabase is open source and the data sits in standard Postgres, so you can export it with normal Postgres tools or move to any Postgres host. That's a real advantage if investors or enterprise clients ask about vendor risk.

Firebase is a Google product with no self-hosted version. Moving away means rewriting data access code and reshaping documents into tables. Supabase publishes a migration path for this: community scripts that export each Firestore collection to JSON and import it as a Postgres table, flattening fields into text, numeric, boolean or jsonb columns. Nested arrays and objects need custom hooks or your own script to split into related tables, and each collection is migrated separately. It works, but plan time for the data modelling, not just the copy.

A quick decision checklist

Write down your five main entities (users, orders, projects and so on) and how they link. Lots of links points to Supabase.
List the reports and admin screens you'll need in year one. Cross-collection reports point to Supabase.
Is it mostly a phone app that must work offline? That points to Firebase.
Estimate reads per user per day. If a single screen loads hundreds of documents, model the Firestore cost before committing.
Check if your team or future hires know SQL. Postgres skills are easy to find.
Decide how much vendor lock-in you can accept.
Whatever you choose, budget time to write and test RLS policies or Security Rules.

What this means for founders and app owners

If you're starting fresh, you can't really go wrong with either, as long as the data model fits the tool. The expensive mistakes come from forcing relational data into Firestore, or from launching a Supabase app with RLS switched off.

If you already have an app built with an AI tool and you're not sure whether the backend is set up safely or will scale, a production audit is the quickest way to find out what needs fixing before real customers arrive. And if you're planning a new product and want help choosing the stack, see how I approach MVP development.

Sources

Supabase pricing
Supabase docs: Database overview
Supabase docs: Migrate from Firestore to Supabase
Google Cloud: Firestore pricing
Google Cloud: Identity Platform pricing
Cover photo: Christopher Gower on Unsplash

Originally published on muhammadmoiz.dev. I'm Muhammad Moiz, a senior full-stack engineer building production apps with React, Next.js and Node.js. If you need a hand with your product, get in touch.

Vibe Coding Security: 8 Holes in Almost Every AI-Built App

Muhammad Moiz — Fri, 30 Oct 2026 05:10:06 +0000

Originally published at muhammadmoiz.dev.

Vibe coding security comes down to one problem: AI app builders are very good at making features work and much less careful about who is allowed to use them. The same handful of holes turn up again and again in AI-built apps, and most of them are about access control, leaked keys and trusting the browser. Below are the 8 that come up most often, how to check for each one in an afternoon, and what to do when you find them.

This is written for founders who built with Lovable, Bolt, Replit, Cursor or v0, and for developers who just inherited one of those projects.

Is Lovable safe? Why AI-built apps share the same weaknesses

The tools themselves are not the problem. The problem is the default architecture they produce. Most AI builders generate a React frontend that talks directly to a backend-as-a-service such as Supabase or Firebase. There is often no server of your own in between. That means the browser is the only place where "rules" live, unless someone deliberately writes them into the database.

This is not a theory. CVE-2025-48757, published on 30 May 2025, describes insufficient Row Level Security in sites generated by Lovable up to 15 April 2025, which let unauthenticated attackers read or write arbitrary tables. The CVE record gives it a CVSS 3.1 base score of 9.3 (critical). Lovable disputes the entry, and the record notes their position that each customer is responsible for protecting their own app's data.

That dispute is the key lesson for any founder: whoever's fault it is, your users' data is your responsibility. The AI tool will not be the one emailing your customers about a breach.

The 8 vibe coding security holes

1. Row Level Security is missing or does nothing

With Supabase, your publishable (anon) key ships inside the frontend. That is by design. Supabase's own docs say requests made with it are limited to whatever Row Level Security allows. So RLS is the actual lock on your data.

The common failures:

RLS is turned off on one or more tables in the public schema.
RLS is on, but a policy like using (true) lets everyone read everything.
Policies check that a user is logged in, but not that the row belongs to them.

A safer pattern for a table where each user owns their rows looks like this:

alter table invoices enable row level security;

create policy "owners read their invoices"
on invoices for select
to authenticated
using ((select auth.uid()) is not null and (select auth.uid()) = owner_id);

Supabase recommends the explicit is not null check because auth.uid() returns null for anonymous requests, and wrapping it in select lets Postgres evaluate it once per query instead of once per row. I covered this hole in depth in Supabase RLS explained.

2. Secret keys shipped to the browser

The Supabase secret key (formerly the service_role key) bypasses every RLS policy. It belongs on a server, in an Edge Function or in a scheduled job, never in frontend code, never in Git. A common way it ends up in client code: an AI assistant "fixes" a permissions error by swapping the publishable key for the secret one.

The same mistake happens with environment variables. In Next.js, any variable prefixed with NEXT_PUBLIC_ is inlined into the JavaScript bundle at build time, so anyone can read it in their browser's dev tools. Other build tools have similar public prefixes. If a payment provider secret, OpenAI key or database password has a public prefix, treat it as leaked: rotate it, then move the call that needs it to the server.

Quick check: open your live site, open dev tools, search the loaded JavaScript for sb_secret_, service_role and the start of any secret key from your payment or AI provider.

3. Security rules that only exist in the UI

Hiding the "Delete" button for non-admins is not security. Neither is a redirect on the admin page. Anyone can call your API, your Supabase tables or your server functions directly with a tool like curl.

The Next.js docs make this point clearly for Server Actions: an exported action can be called with a direct POST request, so the page-level login check does not protect it. Each action needs its own check.

'use server'

import { getSession } from '@/lib/session'
import { db } from '@/lib/db'

export async function archiveProject(projectId: string) {
  const session = await getSession()
  if (!session) throw new Error('Not signed in')

  const project = await db.project.findFirst({
    where: { id: projectId, ownerId: session.userId },
  })
  if (!project) throw new Error('Not found')

  await db.project.update({ where: { id: project.id }, data: { archived: true } })
  return { ok: true }
}

4. Trusting IDs sent from the client (IDOR)

This is the cousin of hole 3. The user is logged in, but the app takes an ID from the URL or request body and loads that record without asking whether it belongs to them. Change /orders/1041 to /orders/1042 and you see a stranger's order. The OWASP name for this is Insecure Direct Object Reference.

The fix is always the same: look up the record using both the ID and the current user (as in the example above), or let RLS enforce ownership in the database.

5. Admin flags and roles the user can edit

AI-generated schemas often put role or is_admin on the same profiles table that users are allowed to update. If the update policy covers the whole row, any user can promote themselves to admin with one request. Another variant reads a role from local storage or a query string, which the Next.js docs specifically call out as untrusted input.

Keep roles in a table users cannot write to, or restrict updates to specific columns, and verify the role on the server every time.

6. File storage that is more public than you think

Uploaded invoices, ID photos and contracts often end up in a public bucket because that made the images load during development. In Supabase, objects in a public bucket can be read by anyone who has the URL, with no policy needed. Supabase does block uploads until you add policies on storage.objects, so AI tools sometimes add a very broad policy to make uploads work.

Use private buckets for anything personal, generate signed URLs when a user needs to view a file, and scope storage policies to a folder per user.

7. No rate limits on expensive actions

Supabase Auth applies rate limits to its own sign-in, sign-up and email endpoints. Your custom functions are a different story. A contact form that sends email, an endpoint that calls an AI model, or a function that writes to the database can be hit thousands of times by a script. The result is a surprise bill, a blacklisted email domain or a flooded database. The Next.js data security guide recommends rate limiting exactly these kinds of operations.

Add per-IP and per-user limits to anything that costs money or sends messages, and set spending caps on your AI provider account.

8. Returning far more data than the screen needs

A select * that sends the full user record to the browser, including email, phone, internal notes or a password reset token, is a leak even if the UI only shows the name. Anything in a network response is visible to the user who received it.

Select only the columns the page needs. In Next.js, the docs recommend a server-only data layer that returns small, safe objects rather than raw database rows.

Photo: Arnold Francisca on Unsplash

Vibe coding best practices: a one-afternoon security checklist

You can work through this list yourself before paying anyone. Each line is a yes/no question.

Check	How to test it	Red flag
RLS on every table	Check each table's RLS status in the Supabase dashboard	Any exposed table with RLS off
Policies scoped to owner	Read each policy's `using` clause	`true`, or no `auth.uid()` reference
No secrets in the bundle	Search the live site's JS in dev tools	`sb_secret_`, `service_role`, any secret key
Server checks on every action	Call an endpoint with curl while logged out	It succeeds
Ownership checks	Change an ID in the URL while logged in	You see another user's data
Roles protected	Try updating your own `role` column via the API	It works
Private storage	Open a document URL in a private window	It loads
Rate limits	Submit a form 50 times quickly	Every request succeeds
Minimal responses	Inspect network responses on profile pages	Fields the UI never shows
.env files out of Git	Check your repo history	A committed `.env`

Test with a second account: Most of these holes only show up when you are logged in as one user and try to reach another user's data. Create two test accounts and try to read, edit and delete each other's records. If you can, so can anyone.

What to do when you find a hole

Rotate anything leaked first. A key that was ever in a public bundle or repository is compromised, even if you remove it now.
Lock down the database. Enable RLS everywhere, then add the narrowest policies that keep the app working. Supabase's docs suggest testing allowed and denied operations for both the anon and authenticated roles.
Move privileged calls to the server. Payments, emails, AI calls and admin operations belong in server routes or Edge Functions.
Check your logs. Look for unusual reads or writes before the fix, in case you need to notify users.
Stop the AI from undoing it. When you prompt for new features, tell the tool explicitly not to change policies or swap keys, and review every diff that touches auth or the database.

What this means for founders and app owners

An AI builder can get you to a working demo in days, and that is genuinely valuable. But "it works" and "it is safe to put real customer data in" are separate milestones. If you are about to take payments, store personal data, onboard a business client or raise money, a security review is part of shipping, not an extra.

If the checklist turned up red flags, or you are not sure how to read the results, a production audit gives you a prioritised list of what is exposed and how to fix it. If you would rather hand the whole thing over, I also take AI-built apps to production, keeping what works and rebuilding what does not.

Sources

I'm Muhammad Moiz, a full-stack developer who builds web apps, SaaS and POS systems, and takes AI-built apps (Lovable, Bolt, Replit) to production. Get in touch.

PHP Critical RCE Vulnerabilities CVE-2026-109618 and CVE-2026-109619: How to Patch

Muhammad Moiz — Fri, 30 Oct 2026 05:10:00 +0000

Originally published at muhammadmoiz.dev.

Two critical bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, can let an attacker run code on a web server without logging in. They were fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and every earlier release on those branches is affected. If your website, WordPress install or API runs on PHP, the fix is to upgrade the PHP runtime, not your plugins or framework.

What happened

The PHP project published two GitHub security advisories on 21 October 2026, both rated Critical with a CVSS v4 score of 9.2. On the same day it shipped patch releases on all four supported branches. The release notes put it bluntly: "There are no complete mitigations, updating is the only safe choice."

The score reflects a network attack that needs no account and no user interaction, but does need certain conditions to line up (that is why attack complexity is marked high). In plain terms: it is not trivial to pull off, but an outsider can attempt it against a public server, and the payoff is full control of the PHP worker process.

Branch	Vulnerable	Fixed in
PHP 8.5	below 8.5.12	8.5.12
PHP 8.4	below 8.4.27	8.4.27
PHP 8.3	below 8.3.36	8.3.36
PHP 8.2	below 8.2.35	8.2.35

Note that the 8.2.35 release notes also remind users that PHP 8.2 reaches end of life on 31 December 2026. Branches older than 8.2 are not listed in the advisories, so treat them as unpatched and unsupported.

The two bugs, explained without the jargon

CVE-2026-109618: memory exhaustion leaves PHP in a broken state

When a PHP request runs out of memory, the engine historically bailed out of whatever it was doing with an abrupt jump. The advisory explains that some code paths make freshly allocated request memory visible before it is fully set up. If any allocation fails at that exact moment, even an unrelated one, the request is left holding half-initialised data, and the shutdown routine later trusts it.

The scary part is how an attacker forces the out-of-memory condition. The advisory lists several ways, including multipart (file upload style) requests with a huge number of headers per part, many empty file fields that still create metadata, and deeply nested field names. Under Apache with mod_php, the researchers confirmed full remote code execution over HTTP with default memory and input limits, before any of your application code even runs. PHP-FPM is believed to be susceptible based on source analysis, but no complete FPM exploit was demonstrated. FrankenPHP and LSAPI are flagged as likely susceptible but not validated.

The fix replaces the abrupt jump with a graceful "soft" out-of-memory stop at a safe point, plus a hard process exit if memory keeps climbing past a second threshold.

CVE-2026-109619: leftover state from a previous request

Long-running PHP workers handle many requests in a row. This advisory describes global state (error, session, object and extension data) that can survive after the memory behind it is freed. A later request that touches that state before normal start-up reads freed memory, which is a classic use-after-free.

Two confirmed paths stand out:

PHP 8.5 with fatal_error_backtraces enabled. The backtrace data is not cleared after a fatal error, and a later diagnostic reads it. This is the basis of the confirmed mod_php exploit.
Session upload progress. This feature is on by default and does not need your code to call session_start(). A fatal error or memory exhaustion during input processing can leave it pointing at freed memory. It was validated against both mod_php and PHP-FPM.

An attacker needs two requests to land on the same worker: one to plant the stale state and one to trigger it. More workers make that harder, but the advisory is clear that it does not remove the risk.

Photo: Taylor Vick on Unsplash

Who is affected

If any of these describe your setup, you should act this week:

A WordPress, WooCommerce, Laravel, Symfony, Drupal or custom PHP site on a PHP version below the fixed releases above.
Apache with mod_php. This is the configuration with confirmed, application-independent exploitation.
PHP-FPM behind nginx or Apache. Exposure is conditional, but session upload progress was validated on FPM.
Docker images that pin an older php:8.x tag and have not been rebuilt since 21 October.
Shared or managed hosting. Your host controls the PHP binary, so you need to confirm they have rolled out the patched build.

Updating WordPress core, a theme or a plugin does nothing here. The bug lives in the language runtime underneath them.

How to patch: a practical checklist

Find your real PHP version. The command-line PHP and the web-server PHP are sometimes different builds, so check both.

# CLI version
php -v

# FPM version (binary name varies by distro, e.g. php-fpm8.3)
php-fpm -v

# Settings that matter for the mitigations below
php -i | grep -E 'memory_limit|session.upload_progress.enabled|fatal_error_backtraces'

For the web server, a temporary phpinfo() page works, but delete it straight after.

Upgrade to the fixed release for your branch. Use your distribution's security repository, your host's control panel, or a rebuilt container image. For Docker, bump the base image tag and rebuild rather than relying on a cached layer.

# Example: confirm the image you ship actually contains the fix
docker run --rm your-app-image php -v

Restart every worker. A new binary on disk does not help while old FPM children or Apache processes stay in memory. Restart the service, not just reload configuration.
Verify in production. Re-run the version check against the live server and record the result.
Plan your branch. If you are on 8.2, schedule a move to 8.3 or newer before the end of December. If you are on anything older than 8.2, upgrading is now urgent rather than optional.

Settings tweaks are a stopgap, not a fix: The advisories say updating is the only complete mitigation. Use the settings below only to reduce risk for the few days it takes to get a patched build deployed.

If you cannot upgrade today

Both advisories list temporary measures. In summary:

Turn off session upload progress (session.upload_progress.enabled=0) and restart workers. The advisory suggests leaving it off even after patching if you don't use it, and most sites don't.
On PHP 8.5, set fatal_error_backtraces=0 at the administrative level and restart. This removes the confirmed exploit path for the second bug, but not every possible one.
Tighten request limits at the edge. Keep post_max_size conservative, cap decoded request size at your reverse proxy or WAF, and block multipart requests entirely on endpoints that never accept uploads.
Lower input limits such as max_input_nesting_level and the number of input variables, parts and uploads.
Avoid RLIMIT_AS and RLIMIT_DATA as a memory cap. The advisory warns these make allocations fail in exactly the way that triggers the first bug.

The first advisory also mentions memory_limit=-1 as a partial configuration mitigation, with the caveat that it is incomplete and that an unbounded memory limit brings its own denial-of-service risk. Treat it with care.

What it means for business and app owners

For a non-technical founder, the short version is this: your website's engine had a serious flaw, and the engine has to be replaced, not the bodywork. Ask whoever runs your hosting or code three direct questions:

Which PHP version is serving our live site right now?
When was it updated, and were all workers restarted?
Are we on a branch that still gets security fixes after this year?

If nobody can answer quickly, that is a sign your stack lacks basic visibility, and a one-off production audit of versions, hosting and patching is usually great value compared with cleaning up after a breach. If you run WordPress and want someone to handle the PHP upgrade and test your plugins against the new version, WordPress development support covers exactly that kind of job.

The broader lesson is that "keep plugins updated" is only half of PHP security. The runtime, the web server and the container image all need an owner and a patch routine, and this month's release is a good prompt to set one up.

Sources

I'm Muhammad Moiz, a full-stack developer who builds web apps, SaaS and POS systems, and takes AI-built apps (Lovable, Bolt, Replit) to production. Get in touch.

Lovable vs Replit vs Bolt vs Cursor: Which to Use, and When You Need a Developer

Muhammad Moiz — Thu, 29 Oct 2026 05:10:58 +0000

Originally published at muhammadmoiz.dev.

Lovable vs Replit comes down to what you want to own at the end. Lovable is the faster path to a polished web app when you mostly describe screens in chat, Replit suits founders who want an AI agent plus a full coding workspace and hosting in one place, Bolt sits between them, and Cursor is a code editor for people (or developers) who already work in a codebase. All four can get you to a working prototype; none of them replaces the engineering work a real product needs once paying users, private data and growth arrive.

Below is a practical comparison written for founders, with prices taken from each vendor's pricing page as of October 2026, plus the signals that tell you it's time to bring in a developer.

Lovable vs Replit vs Bolt vs Cursor at a glance

These tools are often lumped together, but they solve different problems. Three are "describe it and the AI builds it" app builders. Cursor is a different category: an AI-first editor and agent for working inside real code.

	Lovable	Replit	Bolt	Cursor
Best for	Non-technical founders building web apps by chat	Founders who want an agent plus a full dev environment	Quick web apps, prototypes and sites	Developers and technical founders editing real code
How you work	Chat, visual preview	Chat with Agent, plus code editor	Chat, preview, start from Figma or GitHub	IDE, CLI and cloud agents
Backend	Lovable Cloud, billed from your credits	Built-in database and user auth	Built-in databases on every plan	Whatever your project uses
Code ownership	You own your code; GitHub sync	Code lives in your Replit workspace	Can start from your GitHub repo	Your repo from day one
Starting paid price (Oct 2026)	Credit-based Pro and Business plans	Core: $20/month ($18 billed yearly)	Pro: $25/month	Plus: $8/month (Grok models only)

A note on Lovable pricing: its pricing page sells Pro and Business on credits rather than seats, and the plan table didn't load when I checked, so I'm not quoting a number. What the page does confirm is that the free plan gives 5 build credits a day (capped at 30 a month) plus 20 Cloud credits a month, and paid plans add a monthly credit balance on top of those daily grants.

Lovable vs Bolt: which is better for a first version?

Both are aimed at people who want a working web app without writing code, so this is the comparison most founders actually face.

Lovable describes itself as a full-stack engineer you chat with, and it pushes your project to GitHub and deploys in one click. Its newer model puts building, hosting and AI features in your app on one credit balance. Hosting a small app is usually covered by the included grant, but the pricing FAQ is clear that apps with serious traffic or size start drawing on your credits. That's fair, but it means your hosting bill and your "AI typing" bill now share one pot, so watch it as you grow.

Bolt is token-based. The free plan includes 1M tokens a month (with a 300K daily limit), and Pro at $25/month includes 10M tokens with rollover, a custom domain and no Bolt branding. Teams is $30 per member per month. Every plan, including free, lists unlimited databases and hosting, and you can start from a blank prompt, a Figma file or a GitHub repo.

In practice:

Pick Lovable if you want the most guided experience and a clean GitHub handoff later.
Pick Bolt if you want predictable token budgets, want to start from an existing design or repo, or need a custom domain on the entry paid plan.

Lovable vs Replit: what's the real difference?

Replit is a full cloud development environment that grew an AI agent, rather than an AI builder that later exposed the code. That changes how it feels.

According to Replit's product page, its Agent builds from a chat description, uses Replit's own database and user authentication, can connect services like Stripe through stored keys, and periodically tests the app in a browser and fixes what it finds. Core costs $20/month (or $18/month billed yearly) and includes $20 of usage toward the more powerful models. Pro is $100/month ($90 billed yearly) with $100 of credits, up to 10 parallel agents and database rollback up to 28 days.

Photo: Ben Kolde on Unsplash

So the honest answer to "Lovable vs Replit" is:

Lovable is better when the person driving is non-technical and the product is a web app with a typical dashboard, forms and auth.
Replit is better when you want to see and touch everything (files, terminal, database) in the same place, or when the app includes background jobs, bots or scripts that don't fit neatly into a web-app template.

Lovable vs Cursor: different tools for different stages

People compare these because both "write code with AI", but they sit at opposite ends of a project.

Cursor is an editor and agent that works on a real codebase: a desktop IDE, a terminal CLI, cloud agents that work in parallel and review pull requests in GitHub. You choose between models from several labs, including Cursor's own Composer. It also changed hands this year: Cursor's site says it is now part of SpaceX, in a post dated August 14, 2026, and its pricing now bundles Grok models. Plus is $8/month for Grok models only, Premium is $30/month with cloud agents and code reviews, and third-party models on the paid tiers are billed separately by usage.

That makes the decision simple:

If you can't read code, Cursor will feel like being handed the keys to a workshop. Start with an app builder.
If your Lovable or Bolt project is already on GitHub and a developer is now maintaining it, Cursor (or a similar editor) is where that work tends to move.

What about Lovable vs v0?

v0 is Vercel's AI app builder (Vercel's own v0 docs now point to v0.app). I couldn't verify its current plans or features this month, so check its site directly before deciding. The general rule still holds: if your app's success depends on SEO and fast page loads, a framework with server rendering (like Next.js) gives you a better base than a purely client-rendered single-page app.

Which one should you use? A quick decision guide

You're non-technical and need a clickable product to show investors or early users: Lovable or Bolt.
You want an agent, but also a real environment with a database, terminal and hosting: Replit.
You (or your developer) already have a codebase and want AI to speed up the work: Cursor.
You care about search traffic from day one: favour a server-rendered setup such as Next.js, whichever tool generates it.
You're handling payments, health or personal data: use any tool to prototype, but plan a security review before launch.

When the AI tool stops being enough

Every one of these tools is excellent at the first 70% of an app. The trouble shows up in the last 30%, and it usually arrives as one of these:

The AI starts breaking things it fixed yesterday. Each prompt patches one screen and quietly damages another, and credits or tokens burn on going in circles.
Security is "probably fine". Database rules are open, API keys sit in the frontend, or every logged-in user can read every other user's rows. On Supabase-backed apps this is usually a Row Level Security problem; I wrote about it in Supabase RLS explained.
Payments, roles and edge cases get complicated. Subscriptions with upgrades, refunds and team accounts are where generated code gets fragile.
Google can't see your site. A client-rendered app often shows search engines an almost empty page.
You can't hire anyone to maintain it. Nobody can explain how the code is structured, so every change is a gamble.

Keep the AI tool, fix the foundation: Hitting these limits doesn't mean starting over. Export the code to GitHub, get it reviewed, fix the risky parts, and keep building on it with a developer (and AI) in the loop.

What this means for a founder

The tool you start with matters less than the moment you notice it's no longer enough. Use Lovable, Replit or Bolt to learn what users want quickly and spend little doing it. Once the app holds real data or real revenue, treat the generated code like code from any new contractor: review it, secure it and give it a structure someone can maintain.

If you're at that point, I take AI-built apps from Lovable, Bolt and Replit and make them production-ready, or start with a production audit if you just want to know where you stand.

Sources

Lovable pricing and FAQ (checked October 2026)
Replit pricing (checked October 2026)
Replit Agent product page
Bolt pricing (checked October 2026)
Bolt homepage
Cursor pricing (checked October 2026)
Cursor homepage
Vercel v0 documentation
Cover photo: Mohammad Rahmani on Unsplash

I'm Muhammad Moiz, a full-stack developer who builds web apps, SaaS and POS systems, and takes AI-built apps (Lovable, Bolt, Replit) to production. Get in touch.

PostgreSQL 19 Release Candidate: What Shipped, What Was Cut, How to Upgrade

Muhammad Moiz — Thu, 29 Oct 2026 05:10:55 +0000

Originally published at muhammadmoiz.dev.

PostgreSQL 19 is not out yet. The first release candidate shipped on October 15, 2026, and the project now plans general availability for November 19, 2026, later than many teams expected. Several headline features announced in the June beta were pulled before the RC, so if you planned an upgrade around them, this guide covers what actually made the cut, what changes under your feet, and how to get ready.

Where the release stands right now

The PostgreSQL 19 timeline this year has been longer than usual. Here are the dates that matter, all from the project's own announcements:

Milestone	Date
Beta 1	June 4, 2026
Beta 4 (features removed)	September 24, 2026
Release Candidate 1	October 15, 2026
RC 2 and minor updates for supported versions	November 12, 2026 (planned)
PostgreSQL 14 end of life	November 12, 2026
PostgreSQL 19 general availability	November 19, 2026 (planned)

The RC 1 announcement explains that the release team chose to fold a large batch of fixes into version 19 before calling it final, which is why a second release candidate is on the calendar. The GA date can still move if a serious issue turns up.

Why so many late fixes? According to a DEV Community write-up that collects the public discussion, long-time committer Peter Eisentraut wrote on October 9 that LLM-assisted code review was at least partly responsible for the wave of reverts, because it surfaced defects in already-committed features much faster than before. The same write-up notes that some community members pushed back, saying a large share of AI-reported bugs turned out not to be real. Either way, the practical result for you is the same: a smaller, more conservative release.

What was cut from PostgreSQL 19

If you read the Beta 1 announcement and got excited, check this list before you plan anything. The official Beta 4 announcement says these were removed so they can be reconsidered for a later major version:

SQL/PGQ property graph queries (graph-style queries in standard SQL)
Turning data checksums on or off while the cluster is online
Temporal UPDATE and DELETE using FOR PORTION OF
ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS
pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl()

GROUP BY ALL, which appeared in the Beta 1 highlights, is also missing from the current release notes. So if a blog post or tutorial shows any of these as "new in Postgres 19", treat it as outdated.

What did make it in

The good news is that a lot of useful work survived. Based on the RC-era release notes, these are the changes most app developers will notice:

Photo: Domaintechnik on Unsplash

For application code

INSERT ... ON CONFLICT DO SELECT ... RETURNING. An upsert can now hand back the row that already existed instead of silently skipping it. That removes a common "insert, and if nothing came back, run a second SELECT" round trip.
Faster foreign key checks. The notes list a general performance improvement for foreign key constraint checks.
A WAIT command for replicas. A session on a standby can wait until a given WAL position has been written, flushed or replayed. That gives you read-your-writes behaviour when you send writes to the primary and reads to a replica.
More jsonpath string methods, including lower(), upper(), replace(), split_part() and the trim family.
COPY TO can output JSON, with a FORCE_ARRAY option to produce a single JSON array.
Smarter NOTIFY, which now wakes only the backends listening on the relevant channel. Apps that use LISTEN/NOTIFY for real-time features should see less overhead.

Here is the kind of upsert that gets simpler. This is an illustration, not code from the docs:

-- Create a tag if it doesn't exist, and always get its row back
INSERT INTO tags (name)
VALUES ('billing')
ON CONFLICT (name) DO SELECT
RETURNING id, name;

For operations

REPACK, a built-in way to rebuild bloated tables, with a CONCURRENTLY option that avoids blocking reads and writes. It shipped with a narrower scope than first planned, and it received many crash and correctness fixes during the betas, so test it on a copy first.
Parallel autovacuum via autovacuum_max_parallel_workers, plus a new scoring system for deciding which tables to vacuum first.
Automatic I/O worker scaling between the new io_min_workers and io_max_workers settings.
pg_plan_advice and pg_stash_advice, new modules for steering and pinning planner decisions.
Logical replication of sequences, which makes replication-based online upgrades less fiddly.
TLS SNI support through a new pg_hosts.conf file, so one server can present different certificates per hostname.

Breaking changes to check before upgrading

This is the section to read twice. These items come from the migration section and other behaviour changes in the release notes:

JIT is off by default. If you have analytical queries that benefited from JIT compilation, benchmark them and turn it back on explicitly if needed.
RADIUS authentication is gone. The notes describe the UDP-only implementation as unfixably insecure. Move to another method before upgrading.
MD5 password logins now trigger a warning after successful authentication (controlled by md5_password_warnings). It's a nudge to switch to SCRAM.
standard_conforming_strings is always on. Dumps taken from older versions with this setting off will not load correctly into 19.
max_locks_per_transaction defaults to 128 instead of 64, and lock sizing changed. If you tuned this value, the notes say you effectively need to double it to keep the same capacity.
json_array() returns an empty array instead of NULL when there are no rows. Check any code that tests for NULL here.
Default TOAST compression is now lz4 rather than pglz.
vacuumdb --analyze-only now includes partitioned tables when no targets are given.

A quick way to spot settings that matter on your current server:

SELECT name, setting
FROM pg_settings
WHERE name IN (
  'jit',
  'standard_conforming_strings',
  'max_locks_per_transaction',
  'password_encryption',
  'default_toast_compression'
);

And to find roles still using MD5 password hashes (run as a superuser):

SELECT rolname
FROM pg_authid
WHERE rolpassword LIKE 'md5%';

A practical upgrade checklist

Don't run an RC in production: A release candidate is for testing. Wait for the final 19.0 release, and for most teams, for the first minor release after it, before moving production data.

Know your current version. Run SELECT version();. If you're on PostgreSQL 14, that matters more than 19: version 14 stops getting fixes on November 12, 2026. Plan to move to 17 or 18 now, or straight to 19 once it's stable.
Check your provider. Managed services (RDS, Cloud SQL, Supabase, Neon and others) adopt new majors on their own schedules. Look up when they will offer 19 rather than assuming it will be there on day one.
Spin up the RC in a container and restore a recent copy of your database into it. Run your test suite and your slowest real queries.
Work through the breaking-change list above, especially MD5, RADIUS and standard_conforming_strings.
Pick an upgrade method. The project recommends a major-version approach such as pg_upgrade (fast, in place) or pg_dump / pg_restore (slower, cleaner). Logical replication is another option if you need minimal downtime.
Run pg_upgrade --check first against a copy. It reports incompatibilities without changing anything.
Update drivers and ORMs (node-postgres, Prisma, Drizzle, psycopg and so on) in staging, then confirm migrations still run.
Have a rollback plan: a verified backup and a tested restore, not just a backup.

What this means for business and app owners

If you run a SaaS product, an e-commerce store or an internal tool on Postgres, PostgreSQL 19 is not urgent. Nothing in it is a security fix you must rush to apply, and the most eye-catching features were deferred. The more pressing date is November 12: if your database is on version 14, it will stop receiving security patches that day.

A sensible plan for most teams looks like this: get off 14 this quarter, test 19 in staging once it hits GA, and schedule the production upgrade for early 2027 after the first point release. The features that did ship, like ON CONFLICT DO SELECT, replica WAIT and faster foreign key checks, are real quality-of-life wins worth adopting once you're there.

If your app was built quickly, perhaps with an AI builder, and nobody is sure which Postgres version it runs, which auth method it uses, or whether backups restore, that's worth finding out before any upgrade. A production audit covers exactly those questions, and if you need help planning a database move as part of backend work, get in touch.

Sources

I'm Muhammad Moiz, a full-stack developer who builds web apps, SaaS and POS systems, and takes AI-built apps (Lovable, Bolt, Replit) to production. Get in touch.

Offline-First POS: Lessons From Building Oscar in React

Muhammad Moiz — Wed, 28 Oct 2026 07:07:55 +0000

Originally published at muhammadmoiz.dev.

A point of sale system has one job that matters more than any feature: it must keep selling. On a busy Friday night a restaurant can't tell a queue of customers to wait until the Wi-Fi comes back.

When I worked on Oscar, a POS for restaurants and retail businesses in Pakistan, "works offline" wasn't a nice-to-have. It shaped the whole architecture. Here's how an offline-first POS works in the browser, and the lessons I'd pass on to any founder planning one.

What "offline-first" actually means

Many apps say they "work offline" when they really mean they show a friendly error. Offline-first flips the usual design:

The app reads and writes a local database first. The screen never waits for the server.
The server is updated in the background whenever a connection is available.
The cloud stays the source of truth for reporting, so owners still see every branch's sales in one place.

For a cashier, the result is simple: punching an order, taking payment and printing a receipt behave exactly the same with or without internet.

The architecture in one picture

The React app reads and writes a local database in the browser, so it works offline. When a connection is available, a sync process sends local changes to the backend, which updates the main database used for reporting.

React POS app ↔ Local database: Read / write
Local database ↔ Backend API: Sync when online
Backend API → Main database

On Oscar, the local database was WatermelonDB running on browser storage, so there was no app to install. The backend received the synced changes and mapped them to the main database.

Lesson 1: design the data before the screens

With a normal web app you can sketch the UI first and add API calls later. Offline-first doesn't forgive that. Every feature started with data modelling: the tables, the relations between them, and the functions that create, update and query records.

An order, for example, isn't one row. It has items, modifiers, discounts and payments, and all of them must be created locally, in one go, without asking the server for IDs. Here's a simplified model to show the idea:

import { Model } from "@nozbe/watermelondb";
import { children, field, date } from "@nozbe/watermelondb/decorators";

export class Order extends Model {
  static table = "orders";
  static associations = {
    order_items: { type: "has_many", foreignKey: "order_id" },
    payments: { type: "has_many", foreignKey: "order_id" },
  } as const;

  @field("type") type!: "dine_in" | "takeaway" | "delivery";
  @field("status") status!: string;
  @date("created_at") createdAt!: Date;
  @children("order_items") items!: unknown;
  @children("payments") payments!: unknown;
}

If the data model is right, the screens are easy. If it's wrong, every new feature fights the sync.

Lesson 2: sync is a product feature, not a background detail

The hardest bugs in offline apps aren't on the screen. They're in the sync: an order that arrives twice, a discount that disappears, two devices editing the same table. What helps:

Every record is created with its own unique ID on the device, so the server never has to invent one and duplicates are easy to detect.
Changes sync as a batch, so a half-sent order never shows up in reports.
The backend owns the rules for conflicts. When two devices change the same thing, one place decides, the same way every time.

Lesson 3: real-time and offline can live together

Kitchens want orders the moment they're punched. On Oscar, orders reached the Kitchen Display System over WebSockets, and prints went to the right printer (receipt, kitchen or bar) through QZ Tray. Each real-time feature needs its own answer to "what happens offline?", decided at design time, not after the first outage.

For founders: If your product is used at a counter, in a warehouse or on the road, ask early: "What happens when the internet drops?" Adding offline support later usually means rebuilding the data layer.

Lesson 4: test the bad days, not the good ones

An offline-first app needs testing in the conditions it was built for:

Turn the network off in the middle of an order, then back on.
Punch orders on two devices while one is offline.
Close the browser before a sync finishes and reopen it.
Fill the local database with a busy week of orders and check the app is still fast.

These tests find the problems that real customers would otherwise find for you.

Is offline-first right for your product?

It adds real work, so it's worth it when people must keep working without a connection: POS systems, field-service apps, inventory and delivery tools. For a typical SaaS dashboard used at a desk, a well-built online app with good error handling is usually enough.

If you're planning a POS or another app that has to keep working when the internet doesn't, you can read how I built Oscar in the case study, or tell me about your project.

I'm Muhammad Moiz, a full-stack developer who builds web apps, SaaS and POS systems, and takes AI-built apps (Lovable, Bolt, Replit) to production. Get in touch.

Node.js October 2026 Security Release: Brotli RCE and 9 More CVEs

Muhammad Moiz — Wed, 28 Oct 2026 07:07:51 +0000

Originally published at muhammadmoiz.dev.

On October 21, 2026, Node.js shipped security releases that fix 10 vulnerabilities across the 22.x, 24.x and 26.x lines. Four are rated High. The most serious, CVE-2026-111497, is an out-of-bounds write in the bundled Brotli decoder, and the project says it permits remote code execution. To fix it, upgrade to v22.23.4, v24.22.1 or v26.12.1. The advisory lists no workarounds.

This post covers what was fixed, who needs to act, and a step-by-step upgrade checklist for teams and app owners.

What the October 2026 Node.js security release fixes

The official advisory on nodejs.org lists ten CVEs. Here they are, grouped by severity:

CVE	Issue	Severity	Affected lines
CVE-2026-111497	Brotli decoder out-of-bounds write permits remote code execution	High	26.x, 24.x, 22.x
CVE-2026-105482	`dns.resolve` truncates names containing a NUL character	High	26.x, 24.x, 22.x
CVE-2026-105483	TLS certificate hostname bypass when the IP is written in fullwidth digits	High	26.x, 24.x
CVE-2026-106069	TLS certificate hostname bypass when the host loosely resolves to an IP address	High	26.x, 24.x, 22.x
CVE-2026-105481	Keep-alive socket processes a response written before the request was sent	Medium	26.x, 24.x, 22.x
CVE-2026-106072	Non-canonical IPv4 hostnames let DNS SANs authenticate IP endpoints	Medium	26.x, 24.x, 22.x
CVE-2026-106074	`crypto.randomUUID()` and `randomInt()` entropy caches saved into startup snapshots and SEAs	Medium	26.x, 24.x, 22.x
CVE-2026-106070	ZipFile returns attacker-controlled prefix bytes after failed header validation	Low	26.x
CVE-2026-106071	Permission Model filesystem over-grant via wildcard radix lookup	Low	26.x
CVE-2026-106073	Permission Model bypass with `fs.realpathSync`	Low	26.x, 24.x, 22.x

The release also updates several bundled dependencies, including c-ares, OpenSSL (to 3.5.9 on the 22.x and 24.x lines), undici, SQLite (on 22.x) and the root certificate store. The advisory says the certificate update relates to an eMudhra intermediate CA compromise.

The Brotli RCE: why it is the headline

Brotli is a compression format that web servers and browsers use widely, and Node.js ships its own copy of the Brotli library. According to the release notes, the fix for CVE-2026-111497 cherry-picks an upstream Brotli commit. It also exposes a new decoder error constant, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH, so malformed input now produces a clean error.

The problem is in the upstream library itself, not just in Node.js. Google's Brotli project published patched releases (v1.2.1, v1.1.1 and v1.0.10) on the same day, each labeled "out-of-bounds write permits remote code execution" with the same CVE ID. Other runtimes and tools that bundle Brotli may also need updates, so watch the advisories for your other stacks too.

Neither the Node.js advisory nor the Brotli release notes publish exploit details. In practice, the code most worth checking is any code that decompresses Brotli data you don't control. Examples include request bodies sent by clients, responses from third-party APIs, and files uploaded by users. If your app does any of that, treat this as a priority patch.

Photo: Kevin Ache on Unsplash

The TLS and DNS bugs: quieter but still serious

Three of the four High-severity issues involve how Node.js checks who it is talking to.

Two TLS hostname bypasses (CVE-2026-105483, CVE-2026-106069). In some edge cases, Node.js could accept a certificate for the wrong host when the address was written in an unusual form, such as fullwidth digits or a loosely parsed IP. The fix commits are titled "tls: fix ip normalization regression" and "tls: reject non-canonical IP addresses".
DNS NUL-byte truncation (CVE-2026-105482). dns.resolve could truncate a name at a NUL character, so the name that gets resolved is not the one your code passed in. The fix validates inputs for null bytes.

These bugs matter most for apps that build hostnames or URLs from user input. Common examples are webhook senders, link previewers, URL importers and anything that fetches a URL a customer typed in. In those features, a validation gap can turn into server-side request forgery (SSRF) or a man-in-the-middle risk.

A note on random values in snapshots

CVE-2026-106074 is easy to miss. If you build user-land startup snapshots or single executable applications (SEAs), the entropy caches behind crypto.randomUUID() and randomInt() could be saved into the snapshot. As a result, every process started from it would generate the same values. If you use either feature and rely on those functions for IDs or tokens, upgrade and rebuild your snapshots or executables.

Which Node.js versions are affected (and which are end-of-life)

According to the Node.js release schedule:

Node.js 26.x is the Current line. Fixed in v26.12.1.
Node.js 24.x is Active LTS. Fixed in v24.22.1.
Node.js 22.x is Maintenance LTS until April 30, 2027. Fixed in v22.23.4.
Node.js 20.x reached end-of-life on April 30, 2026. Node.js 18.x ended on April 30, 2025, and 25.x ended on June 1, 2026.

End-of-life versions get no patch: The Node.js project states that "End-of-Life versions are always affected when a security release occurs." If you are still on Node.js 20 or older, this release does not fix you. The only real fix is to move to a supported line.

Upgrade checklist for your team

Here is a practical order of operations that works for most teams.

Find every place Node.js runs. Check your servers, Docker images, CI runners, serverless functions, build machines and Electron apps. Don't forget internal tools and cron workers.
Check the version on each one.

node -v
# Patched: v22.23.4+, v24.22.1+ or v26.12.1+

Pin the patched version in config. Update .nvmrc, engines in package.json, your CI setup, and your Docker base images.

{
  "engines": {
    "node": ">=22.23.4 <23 || >=24.22.1 <25 || >=26.12.1"
  }
}

- FROM node:22.23.3-alpine
+ FROM node:22.23.4-alpine

If you use floating tags such as node:22-alpine, rebuild and redeploy anyway. An image built last week still contains the old binary.

Check your hosting platform. On managed platforms and serverless runtimes, check the provider's docs or status page to see when the patched runtime is rolled out, and whether you need to redeploy to pick it up.
Prioritize risky code paths. Start with services that decompress untrusted Brotli data or make outbound TLS or DNS calls to hosts derived from user input.
Rebuild snapshots and SEAs if you use them, so the CVE-2026-106074 fix takes effect.
Run your test suite and smoke tests before rolling out to production. These are patch releases, but bundled dependencies such as OpenSSL and undici also changed.
Plan your exit from Node.js 20 or older if any service is still on an end-of-life line.

What this means for business and app owners

If you run a SaaS product, an online store, or an app someone built for you, you probably have Node.js running somewhere, even if you never chose it. It might sit behind your API, your Next.js frontend, your background jobs or your build pipeline. Apps built quickly with AI tools such as Lovable, Bolt or Replit often run on Node.js too, and nobody may be tracking which version they use.

Here are the questions to ask your developer or agency this week:

Which Node.js version does each part of our app run on?
Have we upgraded to the October 21 patched releases, and when was the last redeploy?
Is anything still on Node.js 20 or older?
Do we have a routine for applying runtime security releases, or do we rely on someone noticing?

If nobody can answer those clearly, the gap is in process, not just this one patch. A production audit can map what you run, how current it is, and where the risky code paths are. If your backend needs a longer-term owner, see Node.js backend development.

Sources

Node.js Security Releases: Wednesday, October 21, 2026 (nodejs.org)
Node.js v24.22.1 release notes (GitHub)
Node.js v22.23.4 release notes (GitHub)
google/brotli releases (GitHub)
Node.js release schedule (GitHub)
Cover photo: FlyD on Unsplash

I'm Muhammad Moiz, a full-stack developer who builds web apps, SaaS and POS systems, and takes AI-built apps (Lovable, Bolt, Replit) to production. Get in touch.

Supabase RLS Explained: The Security Hole in Most AI-Built Apps

Muhammad Moiz — Tue, 27 Oct 2026 10:49:44 +0000

If you built your app with Lovable, Bolt or v0, there's a good chance it runs on Supabase. And there's a real chance that anyone on the internet can read your users' data right now.

Not because Supabase is insecure. Because of one setting that's easy to get wrong: Row Level Security (RLS).

This post explains what RLS is, the mistakes that leave data exposed, and how to check your own app in five minutes.

Why your Supabase key is public (and why that's fine)

Supabase gives every project an API that talks directly to your Postgres database. Your frontend calls it with the anon key (newer projects call it the publishable key).

That key is meant to be public. It ships in your JavaScript bundle, and anyone can open DevTools and copy it.

So what stops someone from using your key to read every row in your profiles or orders table?

Only RLS. RLS policies are rules inside Postgres that decide which rows each request is allowed to see or change. If RLS is off, the public key is effectively a master key to that table.

The 5 mistakes I'd look for first

1. RLS is turned off

Tables created in the Supabase dashboard's Table Editor have RLS enabled by default. Tables created with raw SQL or migrations, which is how many AI tools generate them, often don't.

With RLS off, this request returns every row:

curl 'https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*' \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

2. RLS is on, but the policy allows everything

When you turn RLS on with no policies, Postgres blocks everything and the app "breaks." The quick fix people (and AI tools) reach for is:

create policy "allow all" on profiles
for select using (true);

using (true) means "every row, for everyone." RLS is technically on, but it protects nothing.

3. Reading is protected, but writing isn't

Policies have two parts:

using (...) decides which existing rows you can see, update or delete
with check (...) decides what new or changed rows you're allowed to write

A common gap: a solid select policy, but an insert or update policy without with check. A user can then write rows with someone else's user_id, or update a field like role = 'admin'.

4. The service role key is in the frontend

The service role key (newer projects: secret key) skips RLS completely. It belongs only on a server. If you can find it in your frontend code or .env files that get bundled, rotate it now.

5. Policies trust data the user controls

user_metadata (raw_user_meta_data) can be edited by the user. A policy like "allow if the user's metadata says role = admin" can be bypassed by the user simply editing their own metadata. Store roles in app_metadata or a separate table only your server can write.

What a correct setup looks like

Here's a typical "users only see their own rows" setup for a notes table:

-- 1. Turn RLS on
alter table public.notes enable row level security;

-- 2. Read: only your own notes
create policy "Users can read their own notes"
on public.notes for select
to authenticated
using ( (select auth.uid()) = user_id );

-- 3. Create: only notes that belong to you
create policy "Users can create their own notes"
on public.notes for insert
to authenticated
with check ( (select auth.uid()) = user_id );

-- 4. Update: only your notes, and you can't hand them to someone else
create policy "Users can update their own notes"
on public.notes for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

-- 5. Delete: only your own notes
create policy "Users can delete their own notes"
on public.notes for delete
to authenticated
using ( (select auth.uid()) = user_id );

-- 6. Keep it fast
create index on public.notes (user_id);

Two details worth knowing:

Wrapping auth.uid() in (select ...) lets Postgres evaluate it once per query instead of once per row, which Supabase recommends for performance.
to authenticated means logged-out visitors get nothing, even before the condition runs.

Check your own app in 5 minutes

Step 1: find tables with RLS off. Run this in the Supabase SQL Editor:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

Any table with rowsecurity = false is readable with your public key.

Step 2: look for "allow all" policies.

select tablename, policyname, cmd, qual, with_check
from pg_policies
where schemaname = 'public';

Look for qual or with_check equal to true, and for insert/update policies with an empty with_check.

Step 3: open the Security Advisor. In the Supabase dashboard, the Security Advisor flags tables without RLS and other common issues. Fix everything marked as an error.

Step 4: test as a stranger. Run the curl request from mistake #1 against your important tables. If you get real data back without logging in, that table is exposed.

The bigger picture

None of this is specific to AI tools. I worked with the same idea for years with Firebase security rules: the browser can never be trusted, so every permission has to be enforced in the database or on the server. AI builders are great at getting the screens working. They're less reliable at this invisible layer, because a missing policy doesn't show up as a bug until someone finds it.

If your app handles real user data, it's worth an hour to check before launch.

I'm Muhammad Moiz, a full-stack developer who helps founders take AI-built apps to production. If you'd like a second pair of eyes on your Supabase setup, I offer a fixed-price production audit.