Database and storage

Choose the right place for data

Use a database for structured records such as orders, accounts, and bookings. Use object storage for durable file bytes, with a confirmed object identifier stored alongside the relevant database record. Temporary files and installed dependencies are not a durable data store.

Amazi provides one managed PostgreSQL database per project. One designated server application receives access to it; browser code and unrelated applications do not receive its connection secret. Ask Amazi to identify the application that should own persistence before adding data-dependent features.

The plan capability Open Database Studio controls the user's database management interface and database download in Amazi. It does not prevent the agent from creating tables or working with data at your request, and does not disable application database provisioning, connections, or storage. Project permissions and the safeguards for shared development and production data still apply.

Development is not a separate test database

Development and production use the same managed database, schema, and rows. Saving, deleting, or creating records through Preview can affect the data used by the published application.

Project object storage is also shared across development and production. Use clearly identified test records and files when verifying behavior. A different preview URL does not make a write disposable.

An external database has its own configuration and lifecycle. Connecting it does not make Amazi responsible for its backups, availability, or recovery.

Where project data is stored

Project data on Amazi servers is planned to be hosted in the Netherlands. Changing the interface language does not change the storage region.

External integrations and AI services process the information sent to them under their own terms. The location of Amazi's servers does not establish the location of an external provider's processing. Avoid sending unnecessary personal data, credentials, or confidential files to external services.

Applications can also write diagnostic logs. Depending on your application's logging, these may contain request details or personal data. Check what your application records and avoid logging secrets. Ask support about the available logs and retention before making promises in your application's privacy policy.

For recovery after accidental data loss, contact support with the project, affected data, and approximate time. Available backups and the scope of recovery need to be checked for that incident; source History does not provide a database or file restore point. Keep your own exports when you need independent control over retention.

Data protection and backups

The platform provides the following technical mechanisms:

• Encrypted web connections. Public HTTPS connections to Amazi use TLS. This describes protection in transit; it does not establish encryption of database files, uploaded objects or every internal connection.
• Access controls. Workspace database and file operations require authentication and project permissions. Each managed project database has its own login and password, and access by unrelated database roles is restricted. Storage operations use a project credential kept in server code; download links have a limited lifetime. Your application remains responsible for its users' permissions.
• Operational logs. Infrastructure services and applications produce diagnostic logs. Infrastructure logs rotate by size, so there is no guaranteed retention period in days. These logs do not constitute a complete, immutable audit of every action involving personal data.
• Encrypted backups. The standard backup policy schedules a daily run at 00:00 Moscow time and includes project database dumps and managed uploaded files in an encrypted backup repository. Access to its encryption password is restricted. Backup processing checks database archive readability and repository integrity. These checks do not establish that a complete application recovery has been rehearsed.

Local backups on the production server do not protect against losing that server or its disks. A separately hosted backup location is not established by this documentation. The stores are captured separately, so restoring a database and its files may require checking their consistency. Ask support for the last successful backup, available recovery points and the scope of recovery for your project.

Information for your data-processing records

Ask support for a dated confirmation covering your project: the hosting provider and full physical address of the database, uploaded files and backups; any different storage locations; the measures actually enabled; and the applicable logging and backup retention. Use the confirmed scope when preparing your own records or notifications. This guide does not establish disk encryption, a certified cryptographic product, a personal-data protection level or comprehensive compliance of your application. External services and the permissions implemented in your application must be assessed separately.

Understand migration confirmation

A request to implement a feature can authorize compatible additions, such as a new table or a field that safely preserves existing data and the published application's behavior. Amazi should not ask repeatedly for confirmation merely because the task uses a database.

Changes that delete real data, remove structures in use, or can break production require explicit confirmation of their scope. Even an “add field” operation may be unsafe if existing rows cannot satisfy the new constraint.

Before approving a destructive operation, establish which records or structures are affected and how they could be recovered.

Store application uploads safely

Managed storage is available to server applications. The backend performs authorized upload and download operations; the browser must not receive the project storage credential. Save the confirmed object identifier after an upload succeeds. Download links can expire and should not be treated as permanent object identifiers.

Your application must still implement its own user permissions and validation. A project-level storage connection is not a complete access-control design for your users.

Uploaded files can keep names in Cyrillic and other languages; you do not need to rename them to Latin characters. When building an upload form, ask Amazi to show the specific reason for rejection, such as an empty file, an invalid name, a size limit, or insufficient storage space, so users know what to correct.

Browse stored files

In the workspace's Storage view, browse stored files, search by name or type, sort the list, and download files. Images and text files also have a preview. Select files with the checkboxes and choose Download selected to save one ZIP. The header checkbox selects files matching the current search; selection remains when the search changes. If a file cannot be downloaded, no incomplete ZIP is delivered. Use Refresh to check for new uploads; a loading error offers Retry instead of an empty list.

When copying a project, select Copy Storage files to include application uploads. This is separate from copying database contents and chat attachments. The copy receives independent files with the same object identifiers, so copied database records can continue to reference them.

History is not a data backup

History and restore restore project source and supported configuration, not database rows or stored objects. Restoring old code can make it incompatible with current data. Treat data backup and restoration as separate, explicitly scoped operations, and verify persistence independently from container health.

Download your database

Open Database, select the Database view, and click Download database in the workspace header. The project owner's plan must include Database Studio access. The download is a PostgreSQL .dump archive containing the complete managed database, including its structure and records. It can be restored with PostgreSQL's pg_restore tool. It does not include Storage files, source code, or external databases.

Keep the tab open until the download finishes. If the export fails, retry; archives larger than 1 GB are not supported by this download.

Import or export selected data

File transfers copy files unchanged between the project and a connected device. They require Amazi Desktop for Windows or Linux and access to the relevant folders.

For a database import, first copy the source file into the project. Ask Amazi to inspect its structure and the target schema, then prepare and run a parser or import script in the project runtime. Specify the intended mapping, validation and handling of existing rows. For an export, prepare and verify the output file in the project runtime first, then copy it to your device. Parsing and database writes are separate from file transfer; completing a copy does not mean an import has succeeded. Full database downloads remain available through Export database.

Imports and restoration affect the shared live database. Have Amazi inspect the schema and explain the exact operation before confirming destructive changes. A data transfer does not validate the application’s business rules.

Database and Storage interface

Open Database in the workspace header. The inner switch selects Database or Storage. Database embeds Prisma Studio with a schema selector and table list; “No tables found” means the selected schema currently has no listed tables, not that project source is missing. When your plan does not include the editor, the upgrade notice appears in the center of the editing area. If an access or plan notice appears, resolve that restriction before judging whether the database is empty. Storage is for managed stored objects, separate from source files in Code and message attachments. Opening a database or storage surface does not make edits harmless: the shared data boundary described above still applies.