Hostinger Node.js PostgreSQL hosting: VPS or managed?

Quick answer: A Node.js app that uses PostgreSQL does not automatically need a Hostinger VPS. Hostinger documents a managed Node.js application connected to a Supabase-hosted PostgreSQL database. That can fit an app whose runtime, database connection and deployment workflow match the managed service. A Hostinger VPS is the route for installing PostgreSQL on Hostinger infrastructure yourself, or for server-level control that the managed app product does not supply. The VPS also puts operating the server and database on you. Hostinger’s connection guide and its VPS database guidance describe those different arrangements.

The word hosting hides the important split. In the first arrangement, Hostinger runs the application service while Supabase runs PostgreSQL; you still maintain the app and its data model. In the second, the app and PostgreSQL can run on a Hostinger VPS, but you administer the operating system, database configuration and recovery process. Neither arrangement turns an exported repository into a working production app by itself. Before choosing a plan, find out what the repository actually needs and which service will supply each part.

This guide uses Hostinger and Supabase documentation checked October 4, 2026, and a pre-purchase worksheet for the app owner. Hostinger’s support article currently names Business Web Hosting and Cloud plans for managed Node.js deployment, while its Node.js sales page displays Unlimited and Cloud Startup. Those names have not been reconciled to a specific checkout entitlement, so do not assume Business and Unlimited are interchangeable or choose a cheapest eligible SKU from this guide.

Two workable architectures, with different owners

Suppose a small booking app was exported from an AI coding tool. Its Node.js or Next.js server accepts bookings and writes them to PostgreSQL. The app has ordinary page and API requests, but no known background worker or unusual database extension. That description is a starting point, not enough evidence to buy hosting. The repository may call external services for sign-in, file storage or email; it may run schema migrations during deployment; and a successful local database connection does not prove the production connection will work.

The managed route has two providers. Hostinger’s Supabase integration instructions connect its Node.js app to Supabase using connection settings supplied to the app. Supabase operates the PostgreSQL service. The integration does not copy your tables, alter your ORM, move users, or switch existing storage and functions into Hostinger. If the booking app already uses Supabase and its application code can be deployed on Hostinger’s managed runtime, this route may preserve the current database owner while moving the app server.

The VPS route gives you a machine on which PostgreSQL can be installed. Hostinger advertises a PostgreSQL VPS deployment option and identifies its VPS as self-managed. A setup template may shorten installation, but it is not a managed database contract. Someone must own updates, access rules, monitoring, backups and restoration. A VPS may also be appropriate when the application needs server-level processes or configuration that the managed route cannot supply; that need must be identified in the repository rather than assumed because the app uses PostgreSQL.

The table is an ownership map, not a speed ranking. It does not imply that a small VPS is sufficient for a particular workload or that separating providers makes the app more reliable. If the booking app already uses a working Neon database, keep it in the worksheet as an existing external provider. Hostinger’s published Supabase wizard is evidence for Supabase, not proof that every Neon driver, network endpoint and deployment path works without adjustment. Evaluate ordinary external connectivity before migrating a working database just to use a branded integration.

Take this worksheet to the repository before checkout

Open the exported project and the dashboard for its current database. Record the answers privately; do not paste live credentials into a comparison document. The worksheet turns “it is a Node.js app” into a set of checks you can bring to Hostinger’s current plan and support documentation.

The first row prevents a common mistake with AI-built sites. Hostinger provides export and deployment instructions for sites built with tools such as Lovable and Bolt, but an export might contain a frontend, a Node.js backend, or references to services that remain elsewhere. Inspect the actual server and API routes. If the export only contains static assets, paying for a VPS to “support PostgreSQL” may solve a problem the deployable portion does not have. If server routes write bookings, a static-only route cannot replace the running backend.

The migration row deserves an answer before money changes hands. For a new app, a migration may create its initial tables; for an existing app, it may alter records that users rely on. Identify whether a supported build/deploy hook, CI job or separate approved environment can execute the command with the necessary network access and credentials. If no supported route is available, ask Hostinger to clarify it or consider a deployment environment you can control. Do not make a VPS decision solely because an SSH command was assumed to be the only possible way to run a migration.

Check the database connection the app actually uses

Supabase offers more than one way to connect to PostgreSQL. Its connection guide distinguishes direct connections and pooler options, with network and client-compatibility considerations. Direct connections use IPv6 unless an IPv4 option is available; pooler modes can differ in behavior relevant to prepared statements and migration tools. That does not establish that Hostinger is IPv4-only, nor does it select the correct connection string for your app.

For the booking example, find the application’s ORM or driver and its production connection setting. Does the deployed server use a long-lived process and prepared statements? Does the migration tool need a direct session even if routine requests use a pooler? Does the selected endpoint require SSL settings that the driver can provide? Compare those questions with the actual connection dialog in your Supabase project and the driver documentation. Keep runtime and migration connection settings distinct when their requirements differ. Our PostgreSQL connection pooling guide covers the broader connection-budget question; this purchase decision needs only the endpoint and client fit.

Environment variables have to reach the deployed application without becoming public build output. Hostinger’s Supabase guide describes configuring the connection details, but adding a URL to a dashboard does not make the schema exist or prove the server can read it. Confirm that the variable name matches the code, that the server-side code uses it, and that no secret is baked into a browser bundle. For a provider other than Supabase, verify its endpoint and deployment compatibility directly rather than copying the Supabase integration steps into another service.

Once a candidate plan is selected, rehearse a short acceptance sequence in staging: deploy the server, establish its database connection, execute migrations by the supported route, create one booking, read it back, redeploy, and confirm the record remains. Check an expected failure, such as a temporarily unavailable database, so it produces a useful error rather than a false success. If the app serves real customers, extend the sequence with the authorization and recovery controls in our AI-built app deployment checklist.

The plan card is only part of the cost

There is no defensible single-price comparison for these two architectures yet. Hostinger’s current Node.js product page and deployment support page use different managed-plan names. A sales-page price cannot be assigned to the support page’s Business entitlement without confirming the current market’s checkout and feature list. Introductory monthly equivalents may also require a prepaid term and may differ from renewal; taxes and optional services depend on checkout. Check the complete term and renewal before treating a displayed monthly figure as the ongoing bill.

On the managed route, add the Hostinger app subscription to the selected Supabase database subscription or the actual existing database provider’s bill. Include storage, authentication or functions if the app uses separately priced services. Hostinger’s app backup features do not automatically back up a Supabase project. Find each provider’s backup scope, retention and restore procedure, then make sure someone can restore a representative copy. A working app redeploy and a database restore answer different recovery questions.

On the VPS route, the invoice for the machine is not the full operating cost. The person administering it must schedule system and PostgreSQL updates, secure network access, monitor free disk and database health, make backups outside the failed server’s risk boundary, and test restoration. Hostinger’s managed-hosting explanation distinguishes this responsibility from a managed platform. If you lack that operator, budget for one or keep the database with a managed provider. An advertised PostgreSQL template does not take on the pager when an update, full disk or failed restore affects bookings.

Avoid comparing app-hosting and VPS plan prices as though they buy the same database service. The managed pairing buys two provider services and leaves application correctness with you; the self-managed VPS buys control and an operating job. Which costs less depends on the current checkout, selected external database tier, workload and the value of administration time. None of those can be collapsed into a universal figure from the published pages.

Make the choice from the evidence you have

If the booking app’s server fits Hostinger’s managed Node.js deployment, its PostgreSQL client connects successfully to the chosen external endpoint, and migrations have a supported execution path, the managed Hostinger app plus Supabase PostgreSQL is a coherent arrangement. Keeping an already working external database can be equally coherent after checking its own connection path. Confirm the exact eligible plan in the live checkout because of the Business/Unlimited naming conflict; do not select a product by name alone.

If the repository needs server-level control or a process the managed product cannot run, a VPS may be justified. If the goal is specifically to install PostgreSQL on Hostinger infrastructure, Hostinger documents that as a VPS route. Treat that choice as a commitment to administer the database and prove recovery, not as a purchase of managed PostgreSQL. For readers who have already decided on a self-managed VPS, our Hostinger versus Contabo Node app comparison addresses that later provider choice. For the broader choice between a managed database and one you operate, see the managed PostgreSQL versus VPS comparison.

Bring the completed worksheet to the current product page or support team before ordering. The decisive answer is not whether the app has a .js file or a PostgreSQL URL; it is whether its server, connection, migrations and remaining services have a supported home—and who will restore them when something fails.