A form entries database table is a table of its own in your WordPress database, made only for form entries. Where a form plugin stores entries sounds like a technical detail, but it decides how fast your entries list loads, how big your backups get and how easy it is to delete old data. This guide is for teams and site owners choosing a form plugin, and for developers who want to know what is under the hood. We explain the options, the trade-offs and how Echo Forms does it, in about 5 minutes of reading.
The short version
- Some plugins store each entry as a post, with answers in post meta.
- A custom table keeps entries in one place, in one row each.
- Custom tables stay fast as entries grow into the thousands.
- Echo Forms keeps entries in its own table, wp_echo_form_entries.
Where are form entries stored?
It depends on the plugin. Most use one of two approaches:
| Approach | How it works | As entries grow |
|---|---|---|
| Entries as posts | Each entry is a hidden post; each answer is a row of post meta | The posts and meta tables grow, and every site query shares them |
| A WordPress custom table | Each entry is one row in a table made for entries | Lookups stay quick, and other content is unaffected |
A form with 10 questions and 10,000 entries stored as posts adds 10,000 posts and about 100,000 meta rows to tables your pages and products also use. In a table of its own, the same entries are 10,000 rows that nothing else touches.
Why does a custom table help form plugin performance?
Because databases are fastest when a table holds one kind of thing with the right indexes. Searching, filtering and counting entries in their own table is a direct lookup; doing it through post meta means joining large shared tables. The WordPress developer handbook on creating tables describes how plugins add their own tables for exactly this reason.
How does Echo Forms store entries?
In its own tables in WordPress. Entries live in wp_echo_form_entries, form versions in wp_echo_form_versions and the view and start counts behind the analytics in wp_echo_form_funnel. Each entry is saved before any email goes out, so a mail problem never loses one. We built it this way from the start in Echo Forms, because we expect busy sites to collect entries for years, and a site taking 50 entries a day collects more than 18,000 a year.
How to check where your plugin stores entries, step by step
- Open your hosting panel’s database tool, such as phpMyAdmin.
- Look for tables named after your form plugin.
- If there are none, entries are probably posts: look in the posts table for a type named after the plugin.
- Count the rows, and note how fast the plugin’s entries screen loads.
- Compare after 30 days, as entries grow; a screen that took 1 second and now takes 5 seconds is a warning.
Does the storage affect privacy and backups?
Yes. With entries in their own table, deleting old entries removes them cleanly, without leaving stray meta behind. Echo can delete the saved copy of what people typed after 90 days under Site-wide settings, and with Signature a form can clear its own old entries on a schedule. Backups also stay smaller when you can exclude or trim one table. The your entries guide covers deleting and exporting.
A form entries database table is a quiet advantage that grows with your site. If more than 100 people a month send your forms, or you plan to keep entries for 2 years or more, check where your plugin keeps them. See Echo’s entries features and our guide to managing entries.
Entries stored the fast way
Echo Forms keeps entries in its own database table, with no limit on forms or entries.
