A: Hi there,
Here is the exact breakdown of how records, storage, permitted data types, and queries work in NoCodeBackend:

0. Total Storage Space per Database (Beyond Record Count)

Record Limits (Primary Metric): Platform limits are primarily measured by record counts (rows) per database based on your tier.

Relational Data Storage: Structured data (text, numbers, JSON, dates, indexes) is hosted on enterprise MariaDB/MySQL infrastructure (Oracle Cloud Infrastructure) with generous multi-gigabyte disk volume allocations. There is no artificial megabyte cap on your text/JSON data—as long as your rows are within your plan's record quota, your data is fully accommodated.

Media & Binary Storage (Images, Videos, PDFs): Rather than bloating relational database tables with raw binary files (which harms query performance), NoCodeBackend features a native Cloudflare R2 Object Storage integration. Your media files are stored in your connected Cloudflare R2 bucket, while the database simply stores the file URLs/references in FILE columns.

1. What Exactly is a "Record"? (How Row Limits Work)
To put it straightforwardly:
👉 1 Record = 1 Row in any custom table created by you.

Any new entry counts as a record: Whether you create a table for threads, comments, tags, metadata, or custom_logs—every single new row/entry inserted into any of your tables counts as +1 record toward your database limit.
Multiple columns do not add extra records: A single row can have 2 columns or 50 columns with text, numbers, and complex JSON—it still only counts as 1 record.

2. Permitted Data & Database Storage Policy (Per Our Terms of Service)
Per Section 5 of our Terms of Service (Acceptable Use & Database Storage Policy), NoCodeBackend databases are engineered exclusively for structured, relational, and semi-structured application data.

✅ What IS Allowed & Supported:
Application Entities: Threads, comments, tags, user profiles, engagement history, frameworks, and YouTube video IDs/embed URLs.
Large Text Content: Extensive markdown posts, forum discussions, long comment threads, and transcripts using TEXT or LONGTEXT (supporting up to 4 GB of text per field).
Rich JSON Metadata: Configuration payloads, nested arrays, and document trees using native JSON / LONGTEXT (up to 4 GB).
Disk Storage: Generous multi-gigabyte relational storage hosted on enterprise MariaDB/MySQL infrastructure (Oracle Cloud Infrastructure). As long as your entries are valid structured data within your record limit, storage is fully accommodated.

❌ Prohibited Storage Practices (Terms of Service Section 5):
No Raw Binary Files / BLOBs: Storing raw images, videos, audio, PDFs, or document archives directly within table rows is strictly prohibited.
No Base64-Encoded Media: Storing Base64-encoded media/files in TEXT or LONGTEXT columns to bypass file storage is not permitted (and degrades database indexing).
No Raw Log Ingestion Dumps: Using database tables for high-volume streaming server logs, bulk scraping dumps, or raw backup archives.
Handling Media Uploads: All media, user uploads, and files must be hosted on dedicated Object Storage (such as our integrated Cloudflare R2 integration). Your database rows simply store the public URL or file key in a FILE or VARCHAR column, which is the recommended industry standard.

3. Field, Column & Relationship Limits
Text & JSON Field Size: Up to 4 GB per single field (LONGTEXT).
Number of Fields (Columns) per Record: Supports standard MySQL/MariaDB schema limits (up to ~1,000 columns per table).
Relationships: No artificial limit. You can build as many foreign keys, 1-to-many links, and many-to-many junction tables as your data model needs.
Tables per Database: Unlimited tables on all paid / AppSumo tiers.

4. Searching Across Databases
Instance-Scoped API Calls: Every NoCodeBackend database is an isolated tenant instance with its own dedicated connection pool, credentials, and API endpoints. This guarantees strict security, data sandboxing, and compliance isolation.
Multi-Database Search: Each API call targets a specific database. If your system intentionally splits data across multiple databases (e.g., separate regional or project databases), your frontend/backend client makes concurrent API calls to those endpoints and merges the results.
Multi-Table Search Within a Single Database: Within the same database, you can freely query, filter, and join across related tables (threads, comments, tags, etc.) via relational queries and REST endpoints.

Please let us know if you have any further questions!