How to Create a Website With a Database using TeleportHQ

Creating a website with a database involves four main tasks: organising your information, choosing where to store it, connecting it to your pages, and testing how the published site works. In TeleportHQ, you can use a built-in hosted database or connect a supported database you already manage.

This guide explains both options, shows how databases power blogs, help centers and ecommerce websites, and walks through building a searchable course catalogue. You can apply the same process to directories, resource libraries and other websites built around structured content.

What is a website database, and how does it work?#

A website database stores information that your website needs to display or manage. For a blog, that includes posts and their associated content. For an online store, it includes products and orders. A training website might store courses, instructors, and upcoming sessions.

The database and website have different jobs. The database holds the information; the website presents it through pages and lets people perform the actions you have configured.

Consider a course catalogue. One database record contains the details of a photography course. A listing page displays its title, image, and price alongside other courses. When someone opens the course, a details page shows its full description using the same stored information.

You can update the course record without manually finding and rewriting every place its information appears. The connected pages retrieve the data according to their configuration and caching behaviour.

The terms you need to understand#

You do not need to become a database administrator to build this type of website. A few terms make the setup easier to follow:

A database-driven website combines these stored records with page layouts and application behaviour. The resulting site can contain hundreds of individual pages without requiring you to design each one separately.

People also use the term “web database” for databases accessed or managed through a browser. In this guide, the focus is the database supplying information to your website.

When does a website need a database?#

A database is useful when you need to manage repeated content, organise a growing collection of items, or store activity such as purchases.

Typical reasons include:

• Publishing articles through a shared layout.
• Displaying a catalogue that visitors can search or filter.
• Giving each product, course, or directory listing its own page.
• Maintaining information that appears in several places.
• Storing records created through configured website actions.

A small business website with a few service pages may not need a database. If the information changes rarely and does not follow a repeated structure, editing those pages directly may be enough.

Also, storing content in a database does not automatically determine how a site is rendered. Some websites generate static pages from stored content; others retrieve data when pages are requested. The building method should match how current the information needs to be and what visitors must be able to do.

Examples of database websites you can build with TeleportHQ#

Before creating your own tables, check whether a built-in feature already covers the type of site you need. TeleportHQ offers database-backed features for publishing and selling, alongside tools for creating custom pages from data.

Blogs: manage posts independently from their design#

A blog stores the content of each article separately from the layout that displays it. A shared post template can show the title, author, and article body, while the blog listing presents the collection for browsing.

With TeleportHQ's blog builder, the blog setup connects the content system to listing and post pages. You can customise their appearance and manage posts through the available blog tools or admin interface.

For a company publishing tutorials, this means the editorial team can add another post without duplicating an existing page and rebuilding its content blocks. Categories help readers find related material, while a consistent article design keeps the reading experience familiar.

The database gives the content a structure. Editors still need to decide what belongs in each article, how categories should work, and when a post is ready to publish.

Help centers: organise answers into a searchable resource#

A help center uses similar principles but serves a different reader. Someone arriving at a support article usually has a specific task or problem, so search and category navigation matter as much as the article layout.

TeleportHQ's built-in Help Center creates a searchable help area with pages for articles and categories. Its broader knowledge base capabilities also support building systems around structured documentation and support content.

For example, a software business can organise guides into account setup, billing, and product usage. Updating an instruction means changing the relevant content record, while the shared layout continues to display the article consistently.

Plan categories around the questions customers ask. A category called “Import your data” is more useful to a new customer than one named after the internal team responsible for imports. The database supports the organisation you choose, but it cannot decide whether that organisation makes sense to readers.

Ecommerce: connect the storefront to product and order data#

An ecommerce website uses a database for both public information and operational records. Product data supplies the catalogue and product pages. Purchase activity creates order information that the business needs to process.

TeleportHQ's ecommerce website builder provides setup for storefront pages, checkout and related data. You can customise the shopping experience and configure the services and business rules needed to accept and fulfil orders.

A database connection alone does not create a working shop. The site also needs checkout logic, payment configuration and order handling. Using the ecommerce feature gives you a starting structure for those requirements instead of treating a product list as a complete store.

For a retailer, a useful test is the full purchase journey: a shopper opens a product, chooses what to buy, completes checkout, and receives the expected confirmation. The product page is only one part of that process.

Custom catalogues and directories#

For a custom collection, you can define the records yourself and connect them to reusable page designs. Examples include a supplier directory, a property catalogue or a library of downloadable resources.

The walkthrough below uses a course catalogue because its structure is easy to follow. Visitors will browse courses, narrow the list by topic and open a page with more information. The first version will display information without adding student accounts, paid enrolment or a learning management system.

Keeping that scope clear helps you finish the basic website before introducing more demanding application behaviour.

Choose how to build your website database#

You have two main database routes in TeleportHQ: provision the built-in database or connect an existing supported database. You can also use other types of data sources when the information lives in a spreadsheet, API or headless CMS.

TeleportHQ's database tools bring these options into the website-building workflow. The choice depends on where your information already lives, who maintains it, and where you intend to host the finished project.

Use the built-in option for a new project#

TeleportHQ provides a hosted PostgreSQL database that you can set up from the editor. Each project gets its own database, where you can create tables and manage records.

For the course catalogue, this is a straightforward starting point if you do not already have a data service. You can organise the courses in the same project where you design their pages.

Keep an existing database when it is already the source of truth#

If your organisation maintains course information elsewhere, consider connecting that database rather than creating a second manually maintained copy.

TeleportHQ supports connectors including PostgreSQL, MySQL, MongoDB and Supabase, among others. Different connectors have different setup requirements and editing capabilities. Confirm that your chosen connection supports the operations the project needs.

Connecting a database does not move it to TeleportHQ. Its provider continues hosting it, and your team remains responsible for that service's configuration.

Step 1: Define the content and the visitor journey#

Start by writing down what a visitor should accomplish. For this example, the journey is: browse available courses, find a relevant topic, open a course page, and follow an enquiry link.

That journey suggests two main page types:

• A catalogue page with course cards, search, and category filtering.
• A course details page with the full description and an enquiry action.

You also need a way for your team to add courses and update their information. For the first version, you can manage those records from the database tools in the editor.

The fields should reflect both the listing and details pages. A short summary helps people compare courses; a longer description explains what they will learn after they open one.

Sketch a simple data structure#

A first courses table could use the following fields:

This is an example structure, not a platform requirement. A course catalogue for internal training may not need price or enquiry fields. A public workshop listing may need dates and locations instead.

Use proper data types. Storing duration as a number makes numeric sorting possible. Storing “about ten hours” as free text may read well, but it does not behave like a number when you filter or sort it.

Decide which fields are required. A course should have a title and a unique page identifier. If an image is optional, plan what the page should display when it is missing.

Add relationships when information needs to be shared#

If several courses belong to the same instructor, an instructors table can hold that person's details once. Each course can then reference the relevant instructor record.

This avoids copying the same biography into several courses and having to update every copy when it changes. TeleportHQ's table structure tools support foreign keys for compatible databases, including its built-in database.

Keep the first model small enough to understand. Add relationships only when there is a clear reason; splitting every field into another table makes a beginner project harder to manage.

Step 2: Create or connect the database#

Once you know what you need to store, add the database to your project.

Create a built-in TeleportHQ database#

1. Open Data Sources in the editor's left sidebar.
2. Click the plus button to add a data source.
3. Choose TeleportHQ database and give it a recognisable name.
4. Review the hosting notice and plan limitations.
5. Select Setup TeleportHQ Database.

After setup, the database appears among your project's data sources. Open it to start adding tables. The built-in database setup guide explains the interface and common provisioning issues.

If your project already has a built-in database, use that existing connection. Enabling another feature may have created it earlier.

Connect an external database instead#

For an existing source, choose its connector in Data Sources and provide the requested connection details. These may include a host, database name, and credentials, or a connection string supplied by your provider.

The connection must be reachable from TeleportHQ's servers. Configure the required authenticated access and secure connection settings with your provider.

Fetching the schema lets TeleportHQ discover the available structure. Review the imported tables or collections before connecting them to pages. The external database connection guide covers the supported connectors and their individual requirements.

A successful connection confirms access; it does not prove that every record is suitable for public display. Keep sensitive operational data separate from the information intended for visitors.

Step 3: Create the tables and populate them#

With the database available, build the structure planned in the first step. In the database panel, the Add a new table card provides options for creating tables manually, generating them with AI or importing supported files.

For the course catalogue, create the courses table, add its columns, and set the required field types. Assign a primary key and make the slug field unique so records have distinct public identifiers.

If you prefer AI-assisted setup, describe the table, its fields, and any relationships. Be explicit about required values and which fields should be unique. Review the generated result before adding production content; AI generation uses tokens and still needs your judgment.

The help center explains both approaches in its guide to creating database tables.

Add sample records before importing everything#

Open the table through View Data and add a small set of courses. Make the sample varied enough to test the design:

• A short course title and a much longer one.
• Courses in different categories.
• A course without an optional image.
• A free course, if zero is a valid price for your project.
• Descriptions with different lengths.

This helps expose layout and display issues while they are easy to fix. If all sample records contain the same amount of text, the design may appear finished until actual content is added.

Review the records as a visitor would. “Photography basics” gives little information on its own. A useful summary can explain who the course is for and what someone will learn.

Import data from a spreadsheet#

If the information already exists in a file, you can import it rather than entering every record manually. TeleportHQ supports database imports from formats including CSV and Excel, with other options documented in the import tools.

Clean the source file first. Use clear column names, check that numbers are stored consistently, and remove duplicate slugs. Standardise category values so “Photography” and “photography courses” do not accidentally become separate filters.

There are separate workflows for creating tables from a file and importing a CSV into an existing built-in database table. The latter can match existing records through a key, update matching rows, and add new ones. See the database import instructions for supported formats and limits.

After importing, compare a few source rows with the resulting records. Pay particular attention to dates, decimal values, and empty fields. A completed import is a reason to inspect the result, not a substitute for checking it.

Step 4: Design the listing page and bind it to data#

Your catalogue page should help someone decide which course to open. Create the surrounding layout first: a page heading, a short explanation of the catalogue and an area for the course cards.

Then connect the cards to the database. Data binding tells an element where its displayed value comes from. A heading can read a course title; an image can read the image URL stored in the same record.

For a repeated card layout, TeleportHQ provides an Array Mapper. Add it from the List group in Elements, bind its Source to the courses table and design one card inside it. The element repeats that design for the items returned by the source.

Bind each card to the current course#

Inside the repeated layout, bind the heading, summary and image to the current item's fields. This context tells each card which course it represents.

If every card displays the same title, check whether you accidentally selected one specific database row instead of the current repeated item. This is a binding issue, not usually a problem with the table itself.

The guide to displaying database content on pages explains how to choose dynamic values and connect them to elements.

Make the cards useful for comparison#

Display the information visitors need before opening the details page. For this catalogue, that might be topic, duration and price alongside the summary.

Keep the longer description for the individual course page. A list becomes difficult to scan when every card contains several paragraphs and multiple competing actions.

Check the layout with your longest title and smallest screen size. Avoid fixed heights that cut off essential text, and make the course link easy to select on a phone. If images are part of the card design, use a consistent display ratio so the list remains readable as different images are added.

Missing data also needs a deliberate response. TeleportHQ supports fallback values on relevant bindings, but the published-site behaviour can treat zero and false as fallback cases too. Be careful with a price of zero: a free course should not be incorrectly labelled “Price unavailable.” Test the exact field behaviour before relying on a fallback.

Step 5: add search, filtering and navigation#

A catalogue with a few courses can be browsed manually. As it grows, visitors need controls that narrow the list.

Use search for people who know what they want and categories for those exploring a topic. The controls should reflect the data you have, not every filtering possibility you might add later.

Enable text search#

For a supported data-bound Array Mapper or Table, turn on Enable search. TeleportHQ adds a search input for the list, which you can style to fit the page.

The documented list search matches text fields without requiring matching capitalisation. It is not a general search engine for every data type: numeric, date and boolean fields have different handling.

Try the search in Preview and on the published site. Search for a complete title, part of a title and a phrase that appears in a description. Also test a phrase that returns no results so you can assess the empty state.

Filter by category#

A filter specifies which records qualify for display. For example, a category filter can compare the category field with “Photography.”

To let visitors change that value, connect it to a state controlled by a dropdown or buttons. A fixed filter in the editor creates a fixed selection; it does not automatically create visitor controls.

Decide what happens when the filter is cleared. Visitors need an obvious way to return to all courses, especially after combining a category with a search phrase. TeleportHQ's filtering tools support dynamic values and, for database lists, combinations of conditions. The list filtering guide explains those settings and source-specific differences.

Add pagination and a sensible default order#

Pagination divides a larger collection into manageable groups. Supported TeleportHQ lists let you configure items per page and choose a navigation pattern such as page controls or loading more items.

Choose the number of visible cards based on readability and performance. A page with twelve useful cards is often easier to browse than one that tries to show an entire catalogue at once.

Set an order that fits the content. Alphabetical sorting suits a reference catalogue, while upcoming dates may matter more for scheduled workshops. Check the combined behaviour: search should work within the intended filtered collection, and pagination should not leave visitors on an empty results page after they change a filter.

Step 6: Create a dynamic page for each course#

The course details page uses one design to display a different record at each address. You do not need to build a separate layout for every course.

In Pages, Components & Tree View, create a page for the course layout. Open its menu, enable Is Details Page and select the courses list as its source. Use a field that is unique and populated for every record, such as slug, to identify each URL.

Bind the page's content to the current course. Then connect the links on your catalogue cards to the details page, passing each course's URL value. The details-page setup guide covers that configuration.

An example address could be /courses/beginner-photography. Another course uses the same layout with its own address and content.

Design for the decision someone needs to make#

A details page should answer the questions left open by the catalogue card. For a course, those might include:

• Who is the course suitable for?
• What will participants learn?
• How long does it take?
• What does it cost, if applicable?
• What should someone do to enquire or register?

These questions guide the content model as well as the layout. If every course needs prerequisite information, add a consistent place to store it rather than placing the information randomly inside descriptions.

Test several records on the page. Open their URLs directly, refresh the browser and follow the links from the catalogue. Each route should show the correct course, and the enquiry action should lead to the intended destination.

If you later add paid registration, treat it as an additional workflow with its own requirements. Displaying a price and linking to a course page does not implement payment processing or enrolment.

Step 7: Prepare the database-driven pages for SEO#

Search engines need accessible pages with useful content. The database helps you maintain that content consistently, but simply generating more URLs does not make the website more valuable to searchers.

Give each course a clear title and a description that explains its particular offering. Avoid filling every page with the same generic paragraph and changing only the course name. Readers should be able to understand how one course differs from another.

Set page-specific titles and descriptions#

In TeleportHQ's details-page SEO settings, you can bind the meta title and description to the current record. Dedicated SEO fields are useful when the title or summary shown on the page is not the wording you want to use for search metadata.

Review the resulting values for several records rather than checking only the template. Missing source content can leave individual pages incomplete.

Make the content discoverable#

Link each course from the catalogue or a relevant category page. Use descriptive link text and readable URLs, and provide appropriate alternative text for meaningful images.

After launch, inspect representative public URLs in Google Search Console. Check that the content you want indexed is accessible and that important pages are not accidentally excluded.

Keep the site structure useful for visitors. Build category pages because they help people browse a topic, and give those pages enough relevant content to explain their purpose. Search controls can complement that navigation, but should not be the only way to discover important records.

Step 8: test, publish and verify updates#

Preview the design, publish the site and test the complete journey on the live version. Connections, search and data freshness should be checked where visitors will experience them.

A focused launch check can cover the following:

Test missing optional values as well. A loading state, an empty collection and an error are different situations. Design suitable messages for the states supported by the elements you use, so visitors can understand what happened and what they can do next.

Understand when publishing is required#

Layout and configuration changes need publishing. The published site and editor retrieve data separately, so refreshing the editor is not the same action as publishing a changed page.

For data-connected pages, records can be retrieved without manually recreating each page. Caching and source behaviour affect when updated values appear. If the editor and live site disagree, check the original record, refresh the relevant source and inspect cache settings before assuming the binding is broken.

For built-in blogs and help centers, the pages need to have been published at least once, and articles must have the appropriate published status to appear. Treat content publication and page-design publication as related but distinct parts of the workflow.

Database hosting: where your website's data lives#

Website hosting runs the site visitors open. Database hosting runs the service that stores and retrieves its information. A platform can provide both, or the two services can be managed separately.

With TeleportHQ's built-in database, you do not need to provision a separate database server. The database is hosted for the project and works with sites hosted on TeleportHQ.

That hosting relationship matters if you plan to export the project. The built-in database connection does not work from downloaded code hosted elsewhere. For an external deployment, plan the database connection and any other backend requirements before committing to a setup.

When you connect an external database, it remains with its provider. That gives you continuity with your existing data infrastructure, but it also means maintaining the provider account, capacity and connection settings.

Review limits before launching#

The documented limits for the built-in database differ between trial and paid use:

Limits also apply to tables, columns and indexes. Review the current TeleportHQ database plan limits before importing a large dataset or publishing a site that depends on the database.

Estimate both record count and storage. A directory with short text records and a knowledge base with long articles can have similar numbers of records but different storage needs. External databases follow their own providers' database capacity limits.

Manage data access and ongoing maintenance#

The first version of a catalogue may show only public information. If you later add customer records, private content or editing tools, review access requirements before putting that information into use.

Decide who can read, create, edit and delete each type of record. An administrator updating courses needs different permissions from a visitor browsing them. If users manage their own content, the application must enforce which records each person can access.

TeleportHQ stores database credentials and API keys as project Secrets. Use the intended credential controls and keep sensitive connection details out of page text or public code.

A hidden button or section does not provide data protection by itself. Verify access at the application and data layers, including what a signed-out visitor can retrieve. This is particularly important when a project combines public listings with private operational information.

Establish a manageable update process#

Choose a person or team responsible for the content. Agree on how new records are reviewed and how outdated ones are corrected or removed.

For a training catalogue, a simple process might be:

1. Prepare the course information in the agreed fields.
2. Check the description, price and enquiry destination.
3. Add the record and verify its listing and details page.
4. Review the catalogue regularly for courses that are no longer available.

If the project uses built-in publishing features, use their content-status controls as part of that process. For a custom table, define and implement any required review workflow; adding a status column alone does not automatically restrict public access.

Keep track of fields used by page bindings before changing the table structure. Renaming or deleting a column can affect every page that depends on it. Before a bulk update, understand how records will be matched and how you can restore the data if the import produces an unwanted result.

Common mistakes when building a website with a database#

Most early problems come from a mismatch between the data structure and the interface. The following checks can save time during setup:

Avoid expanding the project before these basics work. Adding more records to a broken binding multiplies the visible problem without solving its cause.

For a first release, the most useful result is a complete, tested journey through accurate content. Additional features should follow a clear need, such as enabling paid bookings or giving instructors access to their own records.

Frequently asked questions#

Can I create a website with a database without writing code?#

Yes. TeleportHQ provides visual tools for database setup, record management and connecting data to page elements. You still need to plan the structure and configure how the site should behave. Advanced workflows or unusual integrations may require additional development.

Can I use my existing database?#

You can connect a supported external database and use its information in the project. Confirm the connector, network access and credentials, along with the operations you need. Support for reading a source does not mean every source offers identical editing or structure-management tools.

Is creating an online database the same as creating a database website?#

No. An online database stores and organises information. A database website adds a visitor-facing interface and the behaviour needed to use that information. Building the website means designing the pages, connecting records and testing the actions people will take.

Does adding a database require a Web App slot?#

Connecting a data source alone does not require a Web App slot in TeleportHQ. Features such as authentication, workflows, ecommerce and the built-in blog or help center enable web app capabilities. Some optional behaviour, including list caching, also requires those capabilities.

Can I export a website that uses database content?#

TeleportHQ's documentation limits code export for data-connected projects to Next.js. Code download is available on Pro and Premium, rather than during the trial. The built-in database connection remains dependent on TeleportHQ hosting, so exporting code is not the same as transferring a working hosted backend.

Should I build custom tables for a blog or online store?#

Start with the built-in feature when it matches your needs. It provides the expected pages and supporting structure for that type of site. Custom tables are useful for a different content model or application, such as the course catalogue in this guide. Review feature requirements before modifying tables used by a built-in system.

Build your first database-powered website#

Begin with the information your visitors need and a small set of representative records. Create or connect the database, build the listing and details pages, and verify the full journey on the published site.

If your project is a blog, help center or store, use the relevant built-in feature as your starting point. For a custom catalogue or directory, define the tables around your content and connect them to reusable layouts. Once the first records display correctly and the update process works, you can grow the collection without redesigning every page.