Hostinger Horizons Data Missing After Publishing: Test vs Live Database Problems

You’ve built an app in Hostinger Horizons, tried it in preview and filled in sample customers, enquiries or bookings. After publishing, those records aren’t on the live website. Or real customers have used the app, but when you open the editor the database appears empty. You ask the AI builder to fix the missing data and worry that it has deleted something important.

If data appears to be missing after publishing a Hostinger Horizons or Hostinger AI Builder app, first establish whether you’re viewing Test data or Live data. In Hostinger’s current integrated backend, preview records and production records are intentionally separate. A missing live field may instead mean the database structure hasn’t been republished. Don’t copy or delete records until you know which situation applies.

Why can a published app have different records from preview?

Hostinger’s current integrated-backend documentation explains two distinct environments. Test data comes from interactions in the editor preview; Live data comes from the published application used by real visitors.

The separation is deliberate. It means you can experiment with dummy customers, forms and content without sending those records into the actual business database. Publishing the app doesn’t automatically convert the dummy records into live orders or customer accounts.

For example, suppose you create five example bookings while testing. You publish the app and log in as a customer. The booking list may be empty because those five records belong only to Test data. That doesn’t prove the production app is broken.

Now consider the opposite situation. A customer completes a live booking, but you inspect the Test data collection in the editor and see nothing. The live record could be safe in the separate Live data view. Always verify the active environment label before concluding that data has disappeared.

Confirm which Hostinger backend your project uses

This matters because Hostinger’s app-building technology has changed. Its current AI Builder guidance covers an integrated backend in agentic mode. Older projects may instead use Supabase or another connected service, and the same Test/Live controls may not apply.

Start by locating the project in your Hostinger account and checking which data-management interface it actually provides. If you see the integrated Data panel, inspect its environment selector. If the project uses a legacy Supabase backend, identify that connection and use the relevant configuration and data tools instead.

Don’t follow an article that tells you to edit PostgreSQL tables directly unless you have confirmed that this is the database your particular app uses. Hostinger warns that conventional hosting file-manager and database-migration tools do not apply to its current integrated backend.

The name of the website builder isn’t enough to infer the architecture. Confirm it from the actual project before taking corrective action.

Compare Test data and Live data safely

In projects using the current integrated backend, open the Data panel and deliberately select Test data. Record the relevant collection names and approximate record counts. Then switch to Live data and compare those same collections.

Use read-only checks at first. If you expect a particular form submission, look for a record identifier, timestamp or other non-sensitive distinguishing detail. Avoid distributing screenshots containing real customers’ names, email addresses or other personal information.

A clear comparison gives you three possible results:

• The records exist in Test data only. They were created in preview and were never production records.
• The records exist in Live data only. They came from the published website and do not belong in the preview dataset.
• The records are absent from both. You need to investigate whether the app saved them successfully and which backend the relevant feature actually calls.

If data is absent from both environments, don’t immediately create replacement records. First establish whether there is another source, such as an external API, old backend, separate account or alternative application version.

Missing database fields aren’t the same as missing rows

A different problem arises when you’ve added a new field, such as phone, status or booking_date, and it appears in preview but not in production. That’s a schema or structure issue rather than missing customer records.

Hostinger’s synchronisation guide explains that structural changes are published to the live backend when you publish the updated project. Test and live records remain separate.

Check whether the field was added to the intended collection, whether the project has been republished and whether the live collection now contains that field. Before doing so on a commercial app, inspect whether changing the schema could affect existing workflows or data validation.

Don’t interpret ‘publish’ as an instruction to import test records into the live database. The two operations are different. Publishing a structure change should not be used as a substitute for a planned data migration.

What if the website accepts a form but the record isn’t saved?

This is more serious than a missing preview sample. A public form might show a success message while failing to create the expected live record. That can cost enquiries, bookings and customer confidence.

Test with one clearly identifiable submission on the published website. Record the time, public URL, input values that are safe to log and the message shown after submission. Then check the corresponding Live data collection.

If the record is absent, inspect the flow that handles form submission. Did the browser send a request? Did it return an error? Is the form writing to a different collection or an external integration rather than to Hostinger’s integrated backend?

A success message generated on the frontend isn’t proof that the backend accepted the write. The application should only confirm success when its intended storage or processing step has completed appropriately.

If the record exists but doesn’t appear on the page, the problem could be a read query, permissions, sorting rule or a filter rather than a failed save. Separate the write operation from the display operation before altering either.

Check that users and permissions behave correctly

An application with multiple customer accounts may restrict records by the logged-in user’s identity. A customer viewing an empty dashboard might not mean the database is empty; it may mean the query doesn’t find records owned by that account.

Compare the account that created the record with the account used to view it. Check that user identifiers, organisation identifiers and ownership rules match the intended design. Do not disable permissions just to make a record appear.

Test with ordinary customer accounts rather than only the app owner’s login. Confirm that one user can see their own bookings while another user cannot. A ‘fix’ that exposes every customer’s records is much worse than an empty screen.

If a business is using the app to process private customer information, preserve the current access rules and get the fault investigated before making broad changes.

Avoid copying test data into production by guesswork

It’s tempting to make production look like preview by manually transferring all example records. This can create duplicate users, invalid references and misleading business reports. Some sample data may contain dummy email addresses or payment states that must never become real customer records.

If there is a genuine business requirement to migrate initial content, treat it as a separate data operation. Confirm what records should be imported, where they came from, how duplicates will be detected and whether relationships and permissions remain valid.

Take an appropriate backup or export first using the supported capabilities of your specific backend. Check the destination and the effect of the import in a controlled test. Don’t run scripts copied from another platform against a database you’ve not identified.

For existing production records, the rule is stricter: never overwrite them with preview data as a quick fix.

What if the project uses the older Supabase connection?

Legacy Horizons projects may use a separate Supabase backend. In that case, investigate its project URL, environment configuration, authentication, tables and permission rules using current documentation for that connection.

You might discover that preview points to one Supabase project and the published app points to another, or that recent changes weren’t deployed to the intended environment. Those situations need an environment comparison, not the current Hostinger integrated Data toggle.

Don’t assume the database can be repaired by republishing if the issue is actually a wrong external project URL or a failed function. Establish the architecture and follow the right diagnostic route.

My general guide to Hostinger Horizons apps not working covers broader application failures; this article focuses on distinguishing test and live records, structure and production writes.

When should you seek a paid diagnostic?

If your missing records are simply preview data, Hostinger’s environment explanation may resolve the confusion. If live enquiries are disappearing, account records aren’t showing for the correct user or a schema change has affected production, further prompting without evidence is a risk.

Through AIWebsiteRepair.com, I can investigate the affected Hostinger application’s actual backend and data flow through a paid diagnostic, where project access allows it. That establishes whether records exist, where the failure occurs and what should be repaired. Any repair or data migration is separately scoped.

My recommendation: identify the backend and environment first, verify one real live record, then diagnose whether the problem is missing data, missing fields, a failed write or an access rule. Protect production information throughout.