# Database Requirements

ONEWEB requires a **relational database** to store both platform configuration data and application transaction data.\
From an architectural perspective, the database layer plays a critical role in ensuring data integrity, performance, and scalability.

The database design for ONEWEB consists of **separate logical areas** for configuration data and transactional data, which can be deployed on the same database instance or on separate instances depending on system design and performance requirements.

***

### Database Architecture Overview

ONEWEB database usage can be divided into two main categories:

* **Platform Configuration Data**\
  Stores configuration and metadata for designers, platform services, and security.
* **Application Transaction Data**\
  Stores runtime data generated by applications and business processes.

These data sets can:

* Reside in the **same database instance**, or
* Be **separated into different instances** for scalability, performance, or security reasons.

***

### Supported Database Platforms

ONEWEB supports the following relational database management systems:

* **Oracle** 11g or later
* **PostgreSQL** 9.6
* **MySQL** 5.6 or later
* **IBM DB2** 10.5 or later
* **Microsoft SQL Server** 2012 or later
* **MariaDB** 10.1.22 or later
* **Tibero** 6.0 or later

> The selected database platform should align with organizational standards, licensing policies, and operational expertise.

***

### Database Schema Requirements

ONEWEB requires **multiple database schemas** to separate platform configuration data from application transaction data.

**Platform Configuration Schemas**

The following schemas are used to store ONEWEB platform configuration and metadata:

* **eaf\_master** – App Designer configuration data
* **pd** – Process Designer configuration data
* **mfd** – Microflow Designer configurations
* **page** – Page Designer configurations
* **asp** – AppSpace configurations
* **dpc2** – Deployment Center configurations
* **iam2** – User identity, authentication, and authorization data
* **dashboard\_widget** – Dashboard and widget configurations
* **survey\_rabbit** – Survey configuration data

> Schema names may be customized depending on organizational naming conventions.

***

### **Application Transaction Schemas**

In addition to configuration schemas, ONEWEB requires schemas for application runtime data:

* **erp\_oneweb** – Application transaction data
* **bpm** – Business process transaction data

These schemas store data generated during application execution and business process runs.

***

### Tablespace Design (Recommended)

For performance and maintainability, it is recommended to design database tablespaces carefully.

Best practices include:

* Using **at least one tablespace per schema**
* Separating **data tables and index tables** into different tablespaces
* Grouping tablespaces based on data size and usage patterns

This approach improves performance tuning and simplifies database maintenance.

***

### Data File Considerations

A **data file** is the physical storage unit of a tablespace.\
Each tablespace must have at least one associated data file.

Recommendations:

* Place data files on **separate physical disks** when possible
* Size data files according to expected growth
* Follow database vendor and DBA guidelines for data file management

> Data file sizing and layout should be planned in collaboration with a database administrator (DBA).

***

### Architectural Considerations

From a platform architecture perspective:

* Small or non‑critical systems may use a **single database instance**
* Large or mission‑critical systems should consider **separating configuration and transaction databases**
* High‑availability and cloud deployments should align database design with redundancy and backup strategies

***

### Summary of Database Requirements

* ONEWEB requires a **relational database**
* Configuration and transaction data are logically separated
* Multiple schemas are used to isolate platform components
* Tablespace and data file separation is recommended for performance
* Database design should scale with application usage


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.onewebstack.com/oneweb-platform-th/getting-started/prerequisites-and-system-requirements/database-requirements.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.