Skip to content

Commit 0124ffc

Browse files
fix
1 parent 10bde4f commit 0124ffc

File tree

6 files changed

+349
-101
lines changed

6 files changed

+349
-101
lines changed

app/faq/page.tsx

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -88,6 +88,14 @@ export default function FAQPage() {
8888
text: "Postgresus is installed in /opt/postgresus/",
8989
},
9090
},
91+
{
92+
"@type": "Question",
93+
name: "Why doesn't Postgresus support PITR (Point-in-Time Recovery)?",
94+
acceptedAnswer: {
95+
"@type": "Answer",
96+
text: "Postgresus intentionally focuses on logical backups rather than PITR for several practical reasons: PITR tools typically need to be installed on the same server as your database; incremental backups cannot be restored without direct access to the database storage drive; managed cloud databases don't allow restoring external PITR backups; cloud providers already offer native PITR capabilities; and for 99% of projects, hourly or daily logical backups provide adequate recovery points without the operational complexity of WAL archiving.",
97+
},
98+
},
9199
],
92100
}),
93101
}}
@@ -249,6 +257,53 @@ export default function FAQPage() {
249257
Postgresus is installed in <code>/opt/postgresus/</code>{" "}
250258
directory.
251259
</p>
260+
261+
<h2 id="why-no-pitr">
262+
Why doesn&apos;t Postgresus support PITR (Point-in-Time
263+
Recovery)?
264+
</h2>
265+
266+
<p>
267+
Postgresus intentionally focuses on logical backups rather than
268+
PITR for several practical reasons:
269+
</p>
270+
271+
<ol>
272+
<li>
273+
<strong>Complex setup requirements</strong> — PITR tools
274+
typically need to be installed on the same server as your
275+
database, requiring direct filesystem access and careful
276+
configuration
277+
</li>
278+
<li>
279+
<strong>Restoration limitations</strong> — incremental backups
280+
cannot be restored without direct access to the database
281+
storage drive
282+
</li>
283+
<li>
284+
<strong>Cloud incompatibility</strong> — managed cloud
285+
databases (AWS RDS, Google Cloud SQL, Azure) don&apos;t allow
286+
restoring external PITR backups, making them useless for
287+
cloud-hosted PostgreSQL
288+
</li>
289+
<li>
290+
<strong>Built-in cloud PITR</strong> — cloud providers already
291+
offer native PITR capabilities, and even they typically
292+
default to hourly or daily granularity
293+
</li>
294+
<li>
295+
<strong>Practical sufficiency</strong> — for 99% of projects,
296+
hourly or daily logical backups provide adequate recovery
297+
points without the operational complexity of WAL archiving
298+
</li>
299+
</ol>
300+
301+
<p>
302+
So instead of second-by-second restoration complexity,
303+
Postgresus prioritizes an intuitive UX for individuals and
304+
teams, making it the most reliable tool for managing multiple
305+
databases and day to day use.
306+
</p>
252307
</article>
253308
</div>
254309
</main>

app/page.tsx

Lines changed: 63 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -579,7 +579,7 @@ export default function Index() {
579579
</div>
580580

581581
{/* Card 7: Many PostgreSQL versions - Mobile/Tablet separate, Desktop merged with card 10 */}
582-
<div className="border-b md:border-r lg:border-r border-[#ffffff20] col-span-1 lg:row-span-2 lg:flex lg:flex-col">
582+
<div className="border-b md:border-r lg:border-r lg:border-b-0 border-[#ffffff20] col-span-1 lg:row-span-2 lg:flex lg:flex-col">
583583
{/* Card 7: Many PostgreSQL versions */}
584584
<div className="p-5 md:p-6 lg:border-b lg:border-[#ffffff20]">
585585
<div className="flex items-center justify-center w-6 h-6 rounded text-sm font-semibold mb-4 border border-[#ffffff20]">
@@ -748,38 +748,27 @@ export default function Index() {
748748
</div>
749749
</div>
750750

751-
{/* Try Postgresus CTA */}
752-
<div className="col-span-1 md:col-span-2 lg:col-span-2 p-5 md:p-6 flex flex-col sm:flex-row items-start sm:items-center justify-between gap-4 bg-[#16181D]">
751+
{/* Card 11: Suitable for clouds */}
752+
<div className="col-span-1 md:col-span-2 lg:col-span-2 p-5 md:p-6 flex flex-col md:flex-row gap-4 md:gap-6">
753+
<div className="flex items-center justify-center w-6 h-6 rounded text-sm font-semibold border border-[#ffffff20] shrink-0">
754+
11
755+
</div>
756+
753757
<div>
754-
<div className="text-lg md:text-xl font-bold mb-2">
755-
Launch Postgresus in 2 minutes
756-
</div>
758+
<h3 className="text-lg md:text-xl 2xl:text-2xl font-bold mb-4 md:mb-5">
759+
Suitable both for self-hosted and cloud databases
760+
</h3>
757761

758-
<p className="text-gray-400 text-sm md:text-base max-w-[350px]">
759-
You&apos;ll only need about 2 minutes to configure Postgresus
760-
and start managing backups
762+
<p className="text-gray-400 text-sm md:text-base">
763+
Postgresus works seamlessly with cloud-hosted PostgreSQL
764+
databases including AWS RDS, Google Cloud SQL, Azure Database.
765+
This is why Postgresus does not support incremental backups:
766+
clouds already have them, but usually you cannot restore
767+
external PITR backup back to the cloud. Hourly and daily
768+
granularity are enough for 99% of even large enterprise
769+
projects
761770
</p>
762771
</div>
763-
764-
<a
765-
href="#installation"
766-
className="w-full sm:w-auto inline-flex items-center justify-center gap-2 px-5 py-2.5 text-black bg-white rounded-lg font-medium hover:opacity-70 transition-colors shrink-0"
767-
>
768-
<span>Get started</span>
769-
<svg
770-
aria-hidden={true}
771-
width="18"
772-
height="18"
773-
viewBox="0 0 24 24"
774-
fill="none"
775-
stroke="currentColor"
776-
strokeWidth="2"
777-
strokeLinecap="round"
778-
strokeLinejoin="round"
779-
>
780-
<path d="M5 12h14M12 5l7 7-7 7" />
781-
</svg>
782-
</a>
783772
</div>
784773
</div>
785774
</div>
@@ -1218,6 +1207,51 @@ export default function Index() {
12181207
question="Is Postgresus an alternative to pg_dump?"
12191208
answer="Yes, Postgresus is a modern alternative to pg_dump. Under the hood, Postgresus uses pg_dump for creating backups, but extends it with a user-friendly web interface, automated scheduling, multiple storage destinations, real-time notifications, health monitoring and backup encryption. Think of Postgresus as pg_dump with superpowers — you get all the reliability of pg_dump plus enterprise features without writing shell scripts."
12201209
/>
1210+
<FaqItem
1211+
number="14"
1212+
question="Why doesn't Postgresus support PITR (Point-in-Time Recovery)?"
1213+
answer={
1214+
<>
1215+
Postgresus intentionally focuses on logical backups rather
1216+
than PITR for several practical reasons:
1217+
<ol className="list-decimal list-inside mt-3 space-y-2">
1218+
<li>
1219+
<strong>Complex setup requirements</strong> — PITR tools
1220+
typically need to be installed on the same server as your
1221+
database, requiring direct filesystem access and careful
1222+
configuration
1223+
</li>
1224+
<li>
1225+
<strong>Restoration limitations</strong> — incremental
1226+
backups cannot be restored without direct access to the
1227+
database storage drive
1228+
</li>
1229+
<li>
1230+
<strong>Cloud incompatibility</strong> — managed cloud
1231+
databases (AWS RDS, Google Cloud SQL, Azure) don&apos;t
1232+
allow restoring external PITR backups, making them useless
1233+
for cloud-hosted PostgreSQL
1234+
</li>
1235+
<li>
1236+
<strong>Built-in cloud PITR</strong> — cloud providers
1237+
already offer native PITR capabilities, and even they
1238+
typically default to hourly or daily granularity
1239+
</li>
1240+
<li>
1241+
<strong>Practical sufficiency</strong> — for 99% of
1242+
projects, hourly or daily logical backups provide adequate
1243+
recovery points without the operational complexity of WAL
1244+
archiving
1245+
</li>
1246+
</ol>
1247+
<br />
1248+
So instead of second-by-second restoration complexity,
1249+
Postgresus prioritizes an intuitive UX for individuals and
1250+
teams, making it the most reliable tool for managing multiple
1251+
databases and day to day use
1252+
</>
1253+
}
1254+
/>
12211255
</div>
12221256
</div>
12231257
</section>

app/postgresus-vs-barman/page.tsx

Lines changed: 70 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -109,9 +109,14 @@ export default function PostgresusVsBarmanPage() {
109109
<tbody>
110110
<tr>
111111
<td>Target audience</td>
112-
<td data-label="Postgresus">Individuals, teams, enterprises</td>
113-
<td data-label="Barman">DBAs, enterprises requiring PITR</td>
112+
<td data-label="Postgresus">
113+
Individuals, teams, enterprises
114+
</td>
115+
<td data-label="Barman">
116+
DBAs, enterprises requiring PITR
117+
</td>
114118
</tr>
119+
115120
<tr>
116121
<td>Interface</td>
117122
<td data-label="Postgresus">Web UI</td>
@@ -124,12 +129,18 @@ export default function PostgresusVsBarmanPage() {
124129
</tr>
125130
<tr>
126131
<td>Recovery options</td>
127-
<td data-label="Postgresus">Restore to any hour or day</td>
128-
<td data-label="Barman">WAL-based PITR (second-precise)</td>
132+
<td data-label="Postgresus">
133+
❌ No PITR (restore to any hour or day)
134+
</td>
135+
<td data-label="Barman">
136+
✅ WAL-based PITR (second-precise)
137+
</td>
129138
</tr>
130139
<tr>
131140
<td>Incremental backups</td>
132-
<td data-label="Postgresus">Full backups with compression</td>
141+
<td data-label="Postgresus">
142+
Full backups with compression
143+
</td>
133144
<td data-label="Barman">rsync-based incremental</td>
134145
</tr>
135146
<tr>
@@ -139,12 +150,16 @@ export default function PostgresusVsBarmanPage() {
139150
</tr>
140151
<tr>
141152
<td>Team features</td>
142-
<td data-label="Postgresus">✅ Workspaces, RBAC, audit logs</td>
153+
<td data-label="Postgresus">
154+
✅ Workspaces, RBAC, audit logs
155+
</td>
143156
<td data-label="Barman">❌ OS-level permissions only</td>
144157
</tr>
145158
<tr>
146159
<td>Notifications</td>
147-
<td data-label="Postgresus">✅ Slack, Teams, Telegram, Email</td>
160+
<td data-label="Postgresus">
161+
✅ Slack, Teams, Telegram, Email
162+
</td>
148163
<td data-label="Barman">❌ Requires custom scripting</td>
149164
</tr>
150165
<tr>
@@ -157,6 +172,20 @@ export default function PostgresusVsBarmanPage() {
157172
<td data-label="Postgresus">One-line script or Docker</td>
158173
<td data-label="Barman">Manual configuration required</td>
159174
</tr>
175+
<tr>
176+
<td>Suitable for self-hosted DBs</td>
177+
<td data-label="Postgresus">✅ Yes</td>
178+
<td data-label="Barman">✅ Yes</td>
179+
</tr>
180+
<tr>
181+
<td>Suitable for cloud DBs</td>
182+
<td data-label="Postgresus">
183+
✅ Yes (RDS, Cloud SQL, Azure)
184+
</td>
185+
<td data-label="Barman">
186+
❌ No (requires filesystem access)
187+
</td>
188+
</tr>
160189
</tbody>
161190
</table>
162191

@@ -328,13 +357,20 @@ export default function PostgresusVsBarmanPage() {
328357
</li>
329358
</ul>
330359

331-
<div className="rounded-lg border border-[#ffffff20] bg-[#1f2937] p-4 my-6">
360+
<div className="rounded-lg border border-[#ffffff20] bg-[#1f2937] px-4 pt-4 my-6">
332361
<p className="text-gray-300 m-0">
333-
<strong className="text-amber-400">Note:</strong> For most applications, restoring to the
334-
nearest hour or day (as Postgresus provides) is sufficient.
335-
Second-precise PITR is typically only required for
336-
mission-critical financial or transactional systems where
337-
every transaction must be recoverable.
362+
<strong className="text-amber-400">Note:</strong> For most
363+
applications, restoring to the nearest hour or day (as
364+
Postgresus provides) is sufficient. Second-precise PITR is
365+
typically only required for mission-critical financial or
366+
transactional systems where every transaction must be
367+
recoverable.{" "}
368+
<Link
369+
href="/faq#why-no-pitr"
370+
className="text-blue-400 hover:text-blue-300"
371+
>
372+
Learn why Postgresus doesn&apos;t support PITR →
373+
</Link>
338374
</p>
339375
</div>
340376

@@ -649,7 +685,9 @@ export default function PostgresusVsBarmanPage() {
649685

650686
<div className="rounded-lg border border-blue-500/30 bg-blue-500/10 p-4 my-6">
651687
<p className="text-blue-300 m-0">
652-
<strong className="text-blue-400">Choose Postgresus if:</strong>
688+
<strong className="text-blue-400">
689+
Choose Postgresus if:
690+
</strong>
653691
</p>
654692
<ul className="text-blue-200 mb-0">
655693
<li>
@@ -673,21 +711,25 @@ export default function PostgresusVsBarmanPage() {
673711
You want quick setup with minimal PostgreSQL expertise
674712
</li>
675713
<li>Built-in backup encryption is important to you</li>
714+
<li>
715+
You use cloud-managed databases (AWS RDS, Google Cloud SQL,
716+
Azure) or self-hosted PostgreSQL
717+
</li>
676718
</ul>
677719
</div>
678720

679-
<div className="rounded-lg border border-[#ffffff20] bg-[#1f2937] p-4 my-6">
721+
<div className="rounded-lg border border-[#ffffff20] bg-[#1f2937] px-4 pt-4 my-6">
680722
<p className="text-white m-0">
681723
<strong>Choose Barman if:</strong>
682724
</p>
683725
<ul className="text-white mb-0">
684726
<li>
685727
You require second-precise Point-in-Time Recovery for
686-
mission-critical systems
728+
mission-critical self-hosted systems
687729
</li>
688730
<li>
689-
You need centralized management of multiple PostgreSQL
690-
servers from a dedicated backup server
731+
You need centralized management of multiple self-hosted
732+
PostgreSQL servers from a dedicated backup server
691733
</li>
692734
<li>
693735
WAL archiving and streaming replication integration is
@@ -701,16 +743,22 @@ export default function PostgresusVsBarmanPage() {
701743
Your organization has dedicated DBA expertise available
702744
</li>
703745
<li>You need Barman-to-Barman geographical redundancy</li>
746+
<li>
747+
You&apos;re building a database platform and need to backup
748+
customer databases with PITR capabilities
749+
</li>
704750
</ul>
705751
</div>
706752

707753
<p>
708754
For most use cases, from individual projects to enterprise
709755
deployments, Postgresus provides the right balance of power and
710-
usability. Barman remains the specialized choice for
711-
organizations with strict PITR requirements and dedicated DBA
712-
teams — it excels in enterprise disaster recovery scenarios
713-
where second-precise recovery is non-negotiable.
756+
usability — and works seamlessly with both self-hosted and
757+
cloud-managed databases. Barman remains the specialized choice
758+
for organizations with strict PITR requirements on self-hosted
759+
infrastructure and dedicated DBA teams, or for teams building
760+
database platforms that need to provide PITR capabilities to
761+
their customers.
714762
</p>
715763
</article>
716764
</div>

0 commit comments

Comments
 (0)