Support 24/7
Client areaGet started
Shared hostingManaged WordPressReseller hostingOpenClaw hostingVPS hostingDedicated serversManaged serversAbout usHow we compareRegionsKnowledge baseSupportDomainsSSLBlogClient area
Platform
Blog / Platform

PostgreSQL on shared hosting: who actually needs it

Nearly every shared hosting plan on the market offers MySQL or MariaDB and nothing else. The result is circular: frameworks default to MySQL because that is what shared hosting has, and shared hosting offers MySQL because that is what frameworks default to. If your stack wants Postgres, you are usually pushed straight to a VPS. Sometimes that push is correct. Often it is not. When you genuinely need PostgreSQL Your framework’s ecosystem assumes it. Django and Rails both run on MySQL, but the

N
Nikolay · Team lead, SRE/DevOps
September 18, 2026 · 3 min read

Nearly every shared hosting plan on the market offers MySQL or MariaDB and nothing else. The result is circular: frameworks default to MySQL because that is what shared hosting has, and shared hosting offers MySQL because that is what frameworks default to. If your stack wants Postgres, you are usually pushed straight to a VPS.

Sometimes that push is correct. Often it is not.

When you genuinely need PostgreSQL

Your framework’s ecosystem assumes it. Django and Rails both run on MySQL, but their documentation, their tutorials and half their third-party packages assume Postgres. On a Django project, ArrayField, JSONField querying, SearchVector full-text search and ExclusionConstraint are Postgres-only. You can avoid all four — you just end up writing more code to do what the framework already does.

You need real transactional DDL. In Postgres, a failed migration rolls back the schema change with it. In MySQL, DDL is not transactional: a migration that fails halfway leaves the schema half-changed, and you fix it by hand at the worst possible moment.

Your data has shape. Arrays, ranges, jsonb with indexes on the keys inside it, proper ENUM types, constraints that actually enforce. MySQL’s JSON support is real but thinner, and its historical willingness to accept values it should have rejected still colours how people write migrations for it.

You need geospatial or full-text search that is more than LIKE. PostGIS has no MySQL equivalent. Postgres full-text search with tsvector and a GIN index handles a surprising amount of what people reach for Elasticsearch to do.

When it is cargo cult

  • WordPress, Joomla, Magento, most PHP CMSes. They are MySQL projects. Running them on Postgres means a compatibility layer, and the plugin ecosystem will break in ways nobody else has debugged.
  • “Postgres is faster.” For the queries a typical CMS or small app runs, on a dataset that fits in RAM, the difference is noise next to a missing index or a page that is not cached.
  • “Everyone serious uses it.” Plenty of serious things run on MySQL at scale. Pick the one your team can operate.

The practical test

Ask three questions.

  1. Does your framework's happy path assume Postgres?Its documentation, its tutorials and half its third-party packages.
  2. Does your schema want a type MySQL does not have?Arrays, ranges, jsonb with indexes on the keys inside it, proper ENUM types.
  3. Do you need a migration to roll back cleanly when it fails?In Postgres a failed migration rolls back the schema change with it. In MySQL, DDL is not transactional.

One yes is enough to justify Postgres. Zero yeses and MySQL is the boring correct answer.

One yes is enough. Zero yeses means MySQL is the boring correct answer, and boring is a feature in a database.

-- the kind of thing that decides it: a JSON key, indexed and queried
CREATE INDEX idx_meta_plan ON accounts USING gin ((meta -> 'plan'));
SELECT id FROM accounts WHERE meta @> '{"plan": "growth"}';

What “PostgreSQL on shared hosting” should mean

Not a checkbox. The things that make it usable:

  • Your own database and role, not a shared cluster user, so GRANT means something.
  • A real connection limit you can see, because Postgres connections are processes and a framework with a careless pool will exhaust them.
  • pg_dump access over SSH, so backups and moves are yours to run, not a support ticket.
  • An admin UI for the times you need to look at a row without opening a terminal.
  • Extensions you can enable — at minimum pg_trgm and uuid-ossp; PostGIS if the host is serious about it.

If a host advertises PostgreSQL but gives you one database with no SSH and no pg_dump, you have a checkbox, not a database.

Every inSave shared and reseller plan includes both MySQL and PostgreSQL — from one Postgres database on Shared Start to 30 on Shared Business, and 25 to 300 across the reseller lines, with SSH and pg_dump on the plans that include shell access. That is the reason Django and Rails projects end up here instead of on a VPS they did not need.

The short version

Postgres earns its place when your framework, your schema or your migrations expect it. If none of those is true, MySQL will serve you fine and you should spend the attention on caching instead. What matters is that the choice is yours — needing Postgres should not be the thing that forces you onto a server you have to administer yourself.