WEBVTT

1
00:00:00.040 --> 00:00:02.560
<v Speaker 1>Your Azure postcrescuil bill isn't high because of traffic. It's

2
00:00:02.640 --> 00:00:05.400
<v Speaker 1>high because of you, specifically because you clicked next one

3
00:00:05.440 --> 00:00:07.799
<v Speaker 1>too many times in the deployment Wizard and trusted the

4
00:00:07.799 --> 00:00:11.199
<v Speaker 1>defaults like they were commandments. Most admins street flexible server

5
00:00:11.240 --> 00:00:13.800
<v Speaker 1>as a set it and forget it managed database. It isn't.

6
00:00:13.839 --> 00:00:16.839
<v Speaker 1>It's a meticulously priced babysitting service that charges by the hour,

7
00:00:16.839 --> 00:00:19.760
<v Speaker 1>whether your kids awake or asleep. This walkthrough exposes why

8
00:00:19.800 --> 00:00:22.519
<v Speaker 1>your so called managed instance behaves like a full time

9
00:00:22.559 --> 00:00:26.519
<v Speaker 1>employee you can't fire. You'll see how architecture choices, storage tears,

10
00:00:26.879 --> 00:00:32.399
<v Speaker 1>ha replicas, auto grow, even Microsoft's recommended settings inflate costs quietly.

11
00:00:32.880 --> 00:00:35.119
<v Speaker 1>And yes, there's one box you tick that literally doubles

12
00:00:35.119 --> 00:00:37.640
<v Speaker 1>your compute bill. We'll reach that by the end. Let's

13
00:00:37.679 --> 00:00:40.799
<v Speaker 1>dissect exactly where the money goes and why Azure's guidance

14
00:00:40.880 --> 00:00:43.840
<v Speaker 1>is the technical equivalent of ordering dessert first and pretending

15
00:00:43.880 --> 00:00:47.359
<v Speaker 1>salad later will balance the bill. The illusion of managed

16
00:00:47.679 --> 00:00:51.759
<v Speaker 1>Administrators love the phrase managed service. It sounds peaceful, like

17
00:00:51.840 --> 00:00:55.840
<v Speaker 1>Azure is out there patching, tuning and optimizing while you nap. Spoiler,

18
00:00:56.320 --> 00:01:00.320
<v Speaker 1>managed doesn't mean free labor. It means Microsoft oper rates

19
00:01:00.359 --> 00:01:03.240
<v Speaker 1>the lights while you still pay the power bill. Flexible

20
00:01:03.280 --> 00:01:07.120
<v Speaker 1>server runs each instance on its own virtual machine, isolated, locked,

21
00:01:07.120 --> 00:01:09.760
<v Speaker 1>and fully built. There's no shared compute ferry floating between

22
00:01:09.760 --> 00:01:12.959
<v Speaker 1>tenants trimming waste. You've essentially rented a VM that happens

23
00:01:12.959 --> 00:01:16.319
<v Speaker 1>to include postgresscal pre installed. When it sits idle, so

24
00:01:16.439 --> 00:01:18.840
<v Speaker 1>does your budget, except the charges don't idle with it.

25
00:01:19.799 --> 00:01:23.159
<v Speaker 1>Most workloads hover at ten to thirty percent CPU, but

26
00:01:23.239 --> 00:01:25.840
<v Speaker 1>the subscription charges you as if the cares are humming

27
00:01:25.920 --> 00:01:28.599
<v Speaker 1>twenty four to seven. That's the VM baseline trap. You're

28
00:01:28.599 --> 00:01:30.959
<v Speaker 1>paying for uptime you'll never use. It's the cloud's version

29
00:01:30.959 --> 00:01:33.719
<v Speaker 1>of keeping your car engine running during lunch. Just in case.

30
00:01:34.439 --> 00:01:37.400
<v Speaker 1>Then come the Burstable skews. Everyone loves these cheap headline

31
00:01:37.439 --> 00:01:41.120
<v Speaker 1>price automatic elasticity. What's not to adore? Here's what Burstable

32
00:01:41.120 --> 00:01:43.599
<v Speaker 1>tiers give you a pool of CPU credits. Each minute

33
00:01:43.599 --> 00:01:46.040
<v Speaker 1>below your baseline earns credit. Each minute above spends it

34
00:01:46.480 --> 00:01:48.879
<v Speaker 1>run long enough without idling, and you drain the bucket

35
00:01:48.920 --> 00:01:52.719
<v Speaker 1>throttling performance to a crawl. Suddenly, the bargain instance spends

36
00:01:52.760 --> 00:01:56.000
<v Speaker 1>its life gasping for compute like a treadmill on low battery.

37
00:01:56.560 --> 00:02:00.040
<v Speaker 1>Designed for brief spurts, many admins unknowingly run them as

38
00:02:00.079 --> 00:02:04.159
<v Speaker 1>full time production notes catastrophic cost per transaction concealed behind

39
00:02:04.280 --> 00:02:08.280
<v Speaker 1>discount pricing. Now Azure touts the stop start feature as

40
00:02:08.280 --> 00:02:11.199
<v Speaker 1>a cost saving hero. It isn't. When you stop the instance,

41
00:02:11.560 --> 00:02:14.800
<v Speaker 1>asure pauses compute billing, but the storage meter keeps ticking.

42
00:02:15.080 --> 00:02:18.280
<v Speaker 1>Your data discs remain mounted, your backups keep accumulating, and

43
00:02:18.319 --> 00:02:21.199
<v Speaker 1>those pleasant sounding gigabytes bill by the second. So yes,

44
00:02:21.199 --> 00:02:23.439
<v Speaker 1>you're saving on CPU burned, but you're still paying rent

45
00:02:23.479 --> 00:02:26.159
<v Speaker 1>on the furniture. Here's the reality check most teams miss.

46
00:02:26.599 --> 00:02:30.520
<v Speaker 1>Migration to flexible server doesn't eliminate infrastructure management. It simply

47
00:02:30.560 --> 00:02:33.199
<v Speaker 1>hides it behind a friendlier interface and a bigger invoice.

48
00:02:33.520 --> 00:02:36.759
<v Speaker 1>You must still profile workloads, schedule stop periods, and right

49
00:02:36.840 --> 00:02:39.840
<v Speaker 1>size compute exactly as if you own the hardware. Managed

50
00:02:39.840 --> 00:02:44.039
<v Speaker 1>means patched, it doesn't mean optimized. Consider managed like hotel housekeeping.

51
00:02:44.240 --> 00:02:46.360
<v Speaker 1>They'll make the bed and replace towels, but if you

52
00:02:46.439 --> 00:02:49.120
<v Speaker 1>leave the faucet running, that water charge is yours. The

53
00:02:49.159 --> 00:02:52.400
<v Speaker 1>first big takeaway treat your postgress equal flexible server like

54
00:02:52.400 --> 00:02:56.599
<v Speaker 1>an on prem host. Measure CPU utilization schedule, startup windows,

55
00:02:56.800 --> 00:03:01.039
<v Speaker 1>avoid burstable lust, and stop imagining that manage equals efficient.

56
00:03:01.879 --> 00:03:06.280
<v Speaker 1>It doesn't. It equals someone else maintaining your environment. While

57
00:03:06.280 --> 00:03:09.639
<v Speaker 1>Azure's meter hums steadily in the background, cheerfully compiling your

58
00:03:09.680 --> 00:03:12.800
<v Speaker 1>next surprise invoice. Now that we've peeled back the automation

59
00:03:12.879 --> 00:03:14.919
<v Speaker 1>with it's time to open your wallet and meet the

60
00:03:14.960 --> 00:03:19.680
<v Speaker 1>real silent predator. Storage, storage the silent bill multiplier. Let's

61
00:03:19.680 --> 00:03:22.680
<v Speaker 1>talk storage, the part nobody measures until the receipt arrives.

62
00:03:23.039 --> 00:03:27.840
<v Speaker 1>In Azure, postgress will Flexible server discs are the hotel minibar, quiet, convenient,

63
00:03:28.159 --> 00:03:30.919
<v Speaker 1>and fatally overpriced. You don't notice the charge until you've

64
00:03:30.960 --> 00:03:34.719
<v Speaker 1>already enjoyed the peanuts. Compute you can stop. Storage never sleeps.

65
00:03:35.000 --> 00:03:37.840
<v Speaker 1>Every megabyte provision has a permanent price tag, whether a

66
00:03:37.840 --> 00:03:41.280
<v Speaker 1>single query runs or not. Flexible server keeps your databased

67
00:03:41.319 --> 00:03:45.000
<v Speaker 1>discs fully allocated even when compute is paused. Because flexible

68
00:03:45.039 --> 00:03:48.319
<v Speaker 1>in as your vocabulary means persistent, idle io still racks

69
00:03:48.360 --> 00:03:51.120
<v Speaker 1>up the bill. Now the main culprit autogrow. It sounds

70
00:03:51.120 --> 00:03:54.560
<v Speaker 1>delightful safety through expansion. The problem it only grows one way.

71
00:03:54.879 --> 00:03:57.120
<v Speaker 1>Once a data disc expands, there is no native auto

72
00:03:57.120 --> 00:04:01.560
<v Speaker 1>shrink that innocent emergency expansion during a batch import. Congratulations,

73
00:04:01.560 --> 00:04:04.919
<v Speaker 1>your storage tea just stayed inflated forever. You can't deflate

74
00:04:04.919 --> 00:04:08.280
<v Speaker 1>it later without manual intervention and downtime. Azure is endlessly

75
00:04:08.319 --> 00:04:11.400
<v Speaker 1>generous when giving you more space. It shows remarkable restraint

76
00:04:11.400 --> 00:04:14.240
<v Speaker 1>when taking any back. And here's where versioning divides the

77
00:04:14.280 --> 00:04:17.600
<v Speaker 1>careless from the economical. There are two classes of premium

78
00:04:17.600 --> 00:04:20.199
<v Speaker 1>SSD V one and V two. With V one price

79
00:04:20.279 --> 00:04:23.439
<v Speaker 1>roughly tracks capacity with modest influence from IOPs and throughput.

80
00:04:23.800 --> 00:04:28.240
<v Speaker 1>With V two, these performance metrics become explicit dials capacity, iopiers,

81
00:04:28.279 --> 00:04:32.480
<v Speaker 1>and bandwidth, priced separately. Most admins here newer equals faster,

82
00:04:32.560 --> 00:04:35.879
<v Speaker 1>and upgrade blindly. What they get instead is three independent

83
00:04:35.920 --> 00:04:39.199
<v Speaker 1>billing streams for resources they'll rarely saturate. It's like paying

84
00:04:39.199 --> 00:04:42.519
<v Speaker 1>business class for storage only to sit in economy surrounded

85
00:04:42.519 --> 00:04:46.240
<v Speaker 1>by five empty seats you technically own. Performance over provisioning

86
00:04:46.319 --> 00:04:49.199
<v Speaker 1>is the default crime developer sized discs, assuming worst case

87
00:04:49.240 --> 00:04:53.000
<v Speaker 1>loads will need ten thousand IOPs just in case reality,

88
00:04:53.319 --> 00:04:56.879
<v Speaker 1>half that requirement never materializes, but your bill remains loyal

89
00:04:56.959 --> 00:05:00.360
<v Speaker 1>to the inflated promise as your's pricing model secretly rewards

90
00:05:00.399 --> 00:05:03.319
<v Speaker 1>panic and punishes data realism. It locks you into paying

91
00:05:03.360 --> 00:05:06.680
<v Speaker 1>for theoretical performance instead of observed need. Then there's the

92
00:05:06.759 --> 00:05:10.360
<v Speaker 1>dev to drift and unholy tradition of cloning production tiers

93
00:05:10.399 --> 00:05:13.160
<v Speaker 1>straight into staging or test. That one TV storage meant

94
00:05:13.160 --> 00:05:15.879
<v Speaker 1>for mission critical workloads is now sitting under a QA

95
00:05:15.959 --> 00:05:19.639
<v Speaker 1>database containing five gigabytes of lorum ipsum. Congratulations, you just

96
00:05:19.680 --> 00:05:22.199
<v Speaker 1>rented a warehouse to store a shoe box. Storage bills

97
00:05:22.240 --> 00:05:26.279
<v Speaker 1>multiply quietly because costs compound across redundancy, backup, retension, and

98
00:05:26.319 --> 00:05:30.480
<v Speaker 1>premium tiers. Each gigabyte gets mirrored, snapshotted, and versioned. Users

99
00:05:30.519 --> 00:05:33.279
<v Speaker 1>think they're paying for disks, they're actually paying for copies

100
00:05:33.319 --> 00:05:36.680
<v Speaker 1>of copies of disks they no longer need. Picture a

101
00:05:36.720 --> 00:05:40.079
<v Speaker 1>real world mishap. A developer requests a small test environment

102
00:05:40.160 --> 00:05:43.199
<v Speaker 1>for a migration mock run. Someone spins up a flexible

103
00:05:43.240 --> 00:05:48.000
<v Speaker 1>server clone with default settings one taabyte premium tier autogrow enabled.

104
00:05:48.439 --> 00:05:51.680
<v Speaker 1>The test finishes, but no one deletes the instance. Months later,

105
00:05:52.279 --> 00:05:55.879
<v Speaker 1>that temporary server alone has quietly drained four digits from

106
00:05:55.920 --> 00:05:59.959
<v Speaker 1>the budget, storing transaction logs for a database no human queries.

107
00:06:00.360 --> 00:06:03.439
<v Speaker 1>The fix is in technology it's restrained cap auto grow

108
00:06:03.600 --> 00:06:07.399
<v Speaker 1>audit disc size, monthly track write latency and IOP's utilization,

109
00:06:07.519 --> 00:06:11.759
<v Speaker 1>then right size to actual throughput, not aspiration for genuine elasticity.

110
00:06:12.120 --> 00:06:15.879
<v Speaker 1>Use premium SSDV too judiciously and dynamically scale performance tiers

111
00:06:15.959 --> 00:06:18.920
<v Speaker 1>via PowerShell or Cli. Instead of baking an access capacity

112
00:06:18.959 --> 00:06:21.720
<v Speaker 1>you'll never touch. Storage won't warn you before it multiplies.

113
00:06:21.720 --> 00:06:24.319
<v Speaker 1>It just keeps billing until you notice. The trick is

114
00:06:24.360 --> 00:06:27.279
<v Speaker 1>to stop treating each gigabyte as insurance and start viewing

115
00:06:27.319 --> 00:06:30.399
<v Speaker 1>it as rented real estate. Trim regularly, claim refunds only

116
00:06:30.480 --> 00:06:33.639
<v Speaker 1>in saved megabytes, and never ever leave a deft database

117
00:06:33.680 --> 00:06:37.279
<v Speaker 1>camping on premium terrain. Fine disks are tamed, but now

118
00:06:37.279 --> 00:06:41.439
<v Speaker 1>comes the monster that promises protection and delivers invoices high availability,

119
00:06:42.360 --> 00:06:46.199
<v Speaker 1>high availability, paying twice for paranoia. High availability sounds noble.

120
00:06:46.279 --> 00:06:50.160
<v Speaker 1>It implies uptime, business continuity, and heroic resilience in as

121
00:06:50.199 --> 00:06:53.519
<v Speaker 1>your post grarescule flexible server. However, HA often means something

122
00:06:53.560 --> 00:06:56.120
<v Speaker 1>far simpler. You're paying for two of everything, so one

123
00:06:56.120 --> 00:06:58.879
<v Speaker 1>can sleep while the other weights to feel useful by default,

124
00:06:59.000 --> 00:07:01.600
<v Speaker 1>enabling HA duplicate. It's your compute and your storage. Every

125
00:07:01.720 --> 00:07:06.879
<v Speaker 1>VCRE every gigabyte perfectly mirrored. Azure calls it synchronous replication,

126
00:07:07.000 --> 00:07:10.079
<v Speaker 1>which sounds advanced until you realize it's shorthand for we

127
00:07:10.199 --> 00:07:13.120
<v Speaker 1>bill you twice to guarantee zero data loss you don't

128
00:07:13.120 --> 00:07:15.519
<v Speaker 1>actually need. The system keeps a stand by replica in

129
00:07:15.600 --> 00:07:19.959
<v Speaker 1>lockstep with the primary, writing every transaction twice before acknowledging success.

130
00:07:20.000 --> 00:07:23.399
<v Speaker 1>Perfect consistency, yes, but at a perfect price double. The

131
00:07:23.439 --> 00:07:26.600
<v Speaker 1>sales pitch says this protects against disasters. The truth most

132
00:07:26.639 --> 00:07:29.519
<v Speaker 1>workloads don't deserve that level of paranoia. If your staging

133
00:07:29.600 --> 00:07:33.040
<v Speaker 1>database goes down for ten minutes, civilization will continue. Analytics

134
00:07:33.079 --> 00:07:35.920
<v Speaker 1>pipelines can catch back up. QA environments don't need a

135
00:07:35.920 --> 00:07:38.639
<v Speaker 1>ghost twin standing by in the next zone doing nothing

136
00:07:38.680 --> 00:07:42.639
<v Speaker 1>but mirroring boredom. Yet countless teams switch on AHA globally

137
00:07:42.680 --> 00:07:46.480
<v Speaker 1>because Microsoft labels it recommended for production, a recommendation that

138
00:07:46.600 --> 00:07:50.439
<v Speaker 1>conveniently doubles monthly revenue. Here's the fun part. The standby

139
00:07:50.480 --> 00:07:53.319
<v Speaker 1>replica can't even do anything interesting. You can't point traffic

140
00:07:53.360 --> 00:07:55.360
<v Speaker 1>at it, you can't run red queries on it. It

141
00:07:55.399 --> 00:07:58.560
<v Speaker 1>sits there, obediently replicating and waiting for an asteroid strike.

142
00:07:58.680 --> 00:08:01.720
<v Speaker 1>Until then it produces zero business value, Yet the meter

143
00:08:01.839 --> 00:08:04.959
<v Speaker 1>spins as if it's calculating p Calling it high availability

144
00:08:05.000 --> 00:08:08.800
<v Speaker 1>is generous. Highly available invoice would be more accurate. Now

145
00:08:08.839 --> 00:08:11.720
<v Speaker 1>does that mean AHA is worthless? No, it's essential for

146
00:08:11.800 --> 00:08:15.240
<v Speaker 1>transactional customer facing systems where every update matters. Think payment

147
00:08:15.279 --> 00:08:18.160
<v Speaker 1>processing or real time inventory. In those cases, losing even

148
00:08:18.199 --> 00:08:21.800
<v Speaker 1>seconds of data hurts, but analytics, staging, and internal tooling

149
00:08:21.920 --> 00:08:24.680
<v Speaker 1>they can survive a reboot. You save thousands simply by

150
00:08:24.680 --> 00:08:27.800
<v Speaker 1>honoring that difference. The smart pattern is tiered durability. Pair

151
00:08:28.000 --> 00:08:31.360
<v Speaker 1>HA only with mission critical workloads and use asynchronous read

152
00:08:31.399 --> 00:08:34.879
<v Speaker 1>replicas for everything else. Read replicas can serve actual queries

153
00:08:34.879 --> 00:08:38.080
<v Speaker 1>while providing failover options. Half the cost, double the usefulness.

154
00:08:38.159 --> 00:08:41.200
<v Speaker 1>But we'll get to their elegance next. Let's talk placement economics.

155
00:08:41.600 --> 00:08:45.519
<v Speaker 1>As your offers availability zones supposedly to spread risk sensible

156
00:08:45.759 --> 00:08:49.039
<v Speaker 1>unless someone interprets that as deploy AHA across three zones

157
00:08:49.080 --> 00:08:52.120
<v Speaker 1>for safety, it's fantastic. Now you're paying triple replication costs

158
00:08:52.120 --> 00:08:55.799
<v Speaker 1>instead of double. With synchronous modes, inter zone latency rises,

159
00:08:55.840 --> 00:08:59.519
<v Speaker 1>performance dips, and financial bleeding accelerates. Remember, spreading risk is

160
00:08:59.559 --> 00:09:02.360
<v Speaker 1>not the same as duplicating it. You don't earthquake proof

161
00:09:02.360 --> 00:09:05.200
<v Speaker 1>a house by building two identical ones side by side.

162
00:09:05.480 --> 00:09:08.320
<v Speaker 1>There's also the false comfort metric of recovery point. Objective

163
00:09:08.879 --> 00:09:12.240
<v Speaker 1>synchronous replication gives a theoretical ARPO of zero, meaning no

164
00:09:12.360 --> 00:09:15.679
<v Speaker 1>data loss, but that assumes failure conditions so coincidental they

165
00:09:15.759 --> 00:09:19.720
<v Speaker 1>border on mythology. Hardware failures, yes, covered, human error deletes

166
00:09:19.759 --> 00:09:23.480
<v Speaker 1>the table. Congratulations, that same precision deletion just replicated perfectly

167
00:09:23.519 --> 00:09:26.960
<v Speaker 1>to your standby. Zero data loss applies only to power failures,

168
00:09:26.960 --> 00:09:29.759
<v Speaker 1>not to bad sequel. You're buying expensive symmetry for the

169
00:09:29.799 --> 00:09:33.440
<v Speaker 1>wrong threat model. Administrators often enable h because they confuse

170
00:09:33.480 --> 00:09:36.960
<v Speaker 1>availability with reliability. They think it's insurance. In reality, it's

171
00:09:36.960 --> 00:09:39.559
<v Speaker 1>a mirror, and mirrors don't fix mistakes. They only show

172
00:09:39.559 --> 00:09:42.799
<v Speaker 1>you two of them. So when designing post rescue flexible

173
00:09:42.840 --> 00:09:47.919
<v Speaker 1>server environments, repeat this quietly. Resilience is not redundancy. Real

174
00:09:47.960 --> 00:09:52.120
<v Speaker 1>resilience means measured recovery, not blind duplication. Protect critical transactions,

175
00:09:52.120 --> 00:09:55.519
<v Speaker 1>ignore vanity staging, and keep paranoia proportional to revenue risk.

176
00:09:55.600 --> 00:09:58.320
<v Speaker 1>You don't need mirror servers for environments nobody cries over.

177
00:09:58.679 --> 00:10:01.200
<v Speaker 1>What you need is architecture that earns its keep. Now

178
00:10:01.240 --> 00:10:04.200
<v Speaker 1>that we've humbled the bodyguard that charges over time, let's

179
00:10:04.240 --> 00:10:07.519
<v Speaker 1>meet the cool cousin who actually pays for himself. Read replicas.

180
00:10:08.039 --> 00:10:12.320
<v Speaker 1>Read replicas overlooked compute capacity if high availability is the

181
00:10:12.360 --> 00:10:16.120
<v Speaker 1>anxious parent hovering over your database's shoulder. Read replicas are

182
00:10:16.159 --> 00:10:19.879
<v Speaker 1>the chill sibling who actually does some work. Their asynchronous relaxed,

183
00:10:19.919 --> 00:10:23.720
<v Speaker 1>and this part's crucial productive. A read replica copies changes

184
00:10:23.759 --> 00:10:26.879
<v Speaker 1>from the primary through streaming replication, but it doesn't force

185
00:10:26.919 --> 00:10:31.200
<v Speaker 1>synchronous acknowledgment translation. Your main database doesn't wait around for

186
00:10:31.240 --> 00:10:34.320
<v Speaker 1>the replica to confirm every transaction before proceeding. That tiny

187
00:10:34.320 --> 00:10:37.519
<v Speaker 1>philosophical difference wait vers don't wait is what makes read

188
00:10:37.559 --> 00:10:41.120
<v Speaker 1>replicas cheaper, faster, and more useful in the real world.

189
00:10:41.279 --> 00:10:44.159
<v Speaker 1>Think of it like photocopying homework. The synchronous ha twin

190
00:10:44.240 --> 00:10:46.559
<v Speaker 1>insists on confirming every line before you hand it in,

191
00:10:46.600 --> 00:10:50.000
<v Speaker 1>so you both fail the deadline gloriously. The asynchronous replica

192
00:10:50.080 --> 00:10:52.320
<v Speaker 1>just makes its own copy later. Maybe it's a few

193
00:10:52.320 --> 00:10:54.720
<v Speaker 1>minutes behind, but at least it's contributing. That few minutes

194
00:10:54.759 --> 00:10:57.480
<v Speaker 1>behind is called replication lag, and for most use cases,

195
00:10:57.519 --> 00:11:01.279
<v Speaker 1>reporting analytics read heavy workloads. It's irrelevant. The primary handles

196
00:11:01.279 --> 00:11:03.799
<v Speaker 1>the rights, the replicas handle the reads, and your users

197
00:11:03.840 --> 00:11:06.559
<v Speaker 1>stay blissfully unaware that the data they're viewing is thirty

198
00:11:06.559 --> 00:11:10.399
<v Speaker 1>seconds vintage. For humans, thirty seconds is still considered real time.

199
00:11:10.679 --> 00:11:13.159
<v Speaker 1>We're not measuring speed here in quantum text. Now here's

200
00:11:13.200 --> 00:11:17.519
<v Speaker 1>where cost meets architecture. Splitting read workloads extends compute capacity

201
00:11:17.679 --> 00:11:21.399
<v Speaker 1>without multiplying subscription waste. Instead of ramping your primary to

202
00:11:21.440 --> 00:11:24.200
<v Speaker 1>a massive VM to handle every query, you distribute reads

203
00:11:24.200 --> 00:11:28.080
<v Speaker 1>to cheaper replicas. You gain throughput, minimize contention, and your

204
00:11:28.120 --> 00:11:32.399
<v Speaker 1>main instance stops hyperventilating underpower bi abuse. The replica pays

205
00:11:32.399 --> 00:11:35.240
<v Speaker 1>for itself because it offsets performance tuning, downtime, and angry

206
00:11:35.279 --> 00:11:39.759
<v Speaker 1>analysts asking why dashboards take geological timeframes to load, but predictably,

207
00:11:39.759 --> 00:11:43.480
<v Speaker 1>there's an achilles heel. Cascading replicas on paper. A zuo

208
00:11:43.559 --> 00:11:46.200
<v Speaker 1>lets you chain them. Replica of a replica up to

209
00:11:46.240 --> 00:11:49.639
<v Speaker 1>several layers deep sound scalable. In practice, every hob adds

210
00:11:49.720 --> 00:11:52.399
<v Speaker 1>latency and cost each new replica inherits. The full price

211
00:11:52.440 --> 00:11:55.399
<v Speaker 1>tag of a standalone VM five per primary might sound

212
00:11:55.399 --> 00:11:58.200
<v Speaker 1>generous until you realize each one is basically another flexible

213
00:11:58.240 --> 00:12:01.360
<v Speaker 1>server contract wearing a fake mustache. Unless you're running a

214
00:12:01.559 --> 00:12:05.360
<v Speaker 1>multi region analytics empire, one or two targeted replicas are plenty.

215
00:12:05.759 --> 00:12:09.360
<v Speaker 1>Beyond that, you're just sponsoring Microsoft's next quarterly bonus. Speaking

216
00:12:09.399 --> 00:12:12.360
<v Speaker 1>of efficiency, as you as virtual endpoints deserve credit. They

217
00:12:12.360 --> 00:12:15.279
<v Speaker 1>are the unsung automation layer in this story. Rather than

218
00:12:15.320 --> 00:12:18.440
<v Speaker 1>pointing applications to individual servers, you can assign a writer

219
00:12:18.559 --> 00:12:21.840
<v Speaker 1>listener and a reader listener. The writer pointer always tracks

220
00:12:21.879 --> 00:12:25.240
<v Speaker 1>whichever node currently handles rights. If you promote a replica

221
00:12:25.360 --> 00:12:29.759
<v Speaker 1>or experience failover, no connection strings need rewriting. The reader

222
00:12:29.799 --> 00:12:33.080
<v Speaker 1>points to your chosen replica for reporting. It's simple DNS

223
00:12:33.120 --> 00:12:36.559
<v Speaker 1>trickery that avoids human panic during failover events. The optimal

224
00:12:36.559 --> 00:12:40.279
<v Speaker 1>pattern keep one synchronous a replica in region for zero

225
00:12:40.399 --> 00:12:44.039
<v Speaker 1>data lost critical workloads, and one asynchronous read replica cross

226
00:12:44.080 --> 00:12:47.360
<v Speaker 1>region for dr and analytics. Anything beyond that and you've

227
00:12:47.399 --> 00:12:50.679
<v Speaker 1>wandered from resilience into vanity ownership. The beauty here is

228
00:12:50.720 --> 00:12:54.039
<v Speaker 1>economic gravity. Read replicas earn their keep by working. They

229
00:12:54.039 --> 00:12:58.639
<v Speaker 1>offload queries, serve insights, and support failover without demanding constant duplication.

230
00:12:58.960 --> 00:13:02.639
<v Speaker 1>HA protects replicers pay rent choose employees over babysitters. And

231
00:13:02.679 --> 00:13:05.320
<v Speaker 1>now that we've given your compute layers something useful to do,

232
00:13:05.559 --> 00:13:09.279
<v Speaker 1>let's examine the quiet monthly thief, undoing all your effort maintenance,

233
00:13:09.919 --> 00:13:13.759
<v Speaker 1>maintenance and hidden downtime costs. Maintenance the cloud's version of

234
00:13:13.919 --> 00:13:18.480
<v Speaker 1>routine dental work. It's necessary, occasionally painful, and always seems

235
00:13:18.480 --> 00:13:22.279
<v Speaker 1>to occur at the worst possible moment. In Azure, postgrescul

236
00:13:22.320 --> 00:13:26.759
<v Speaker 1>flexible server maintenance hides under the friendly label system managed updates.

237
00:13:26.960 --> 00:13:30.960
<v Speaker 1>What that really means is your database will unexpectedly reboot

238
00:13:31.080 --> 00:13:34.360
<v Speaker 1>whenever Microsoft feels like flossing. Here's the anatomy. There are

239
00:13:34.399 --> 00:13:37.480
<v Speaker 1>two types of updates, minor and major. Minor updates a

240
00:13:37.519 --> 00:13:41.279
<v Speaker 1>new patch, OS tweak or micro version of postgresscull run

241
00:13:41.320 --> 00:13:44.600
<v Speaker 1>automatically inside a maintenance window once per month. Major ones

242
00:13:44.799 --> 00:13:48.279
<v Speaker 1>version upgrades like fifteen to sixteen are manual, meaning Azure

243
00:13:48.360 --> 00:13:50.279
<v Speaker 1>waits for you to press the big red button before

244
00:13:50.279 --> 00:13:53.960
<v Speaker 1>breaking your weekend system. Managed windows look convenient. Azure picks

245
00:13:54.000 --> 00:13:56.679
<v Speaker 1>the time zone, chooses an hour, and gives you about

246
00:13:56.720 --> 00:14:01.120
<v Speaker 1>five days notice before rebooting your precious transactional engine. Accept emergencies,

247
00:14:01.159 --> 00:14:05.039
<v Speaker 1>ignore calendars. If a critical security floor appears. Microsoft won't

248
00:14:05.039 --> 00:14:08.519
<v Speaker 1>politely wait for Saturday night, It'll patch immediately. Your charming

249
00:14:08.559 --> 00:14:11.639
<v Speaker 1>five day warning dissolves into surprise downtime. Now throw high

250
00:14:11.639 --> 00:14:15.600
<v Speaker 1>availability into the mix. During upgrades, the system momentarily disables

251
00:14:15.639 --> 00:14:18.080
<v Speaker 1>the AJA link. Both primary and stand by end up

252
00:14:18.120 --> 00:14:23.120
<v Speaker 1>rebooting sequentially. Congratulations, double downtime neatly achieved in pursuit of reliability.

253
00:14:23.399 --> 00:14:25.960
<v Speaker 1>The irony isn't lost on anyone paying for always on,

254
00:14:26.600 --> 00:14:30.759
<v Speaker 1>minor misconfiguration, accidental overlap across time zones, and suddenly your

255
00:14:30.759 --> 00:14:34.519
<v Speaker 1>production workload enjoys a synchronized nap. The fix is ironically simple,

256
00:14:34.639 --> 00:14:38.240
<v Speaker 1>yet rarely used. Control your own calendar, assigned system manage

257
00:14:38.240 --> 00:14:41.879
<v Speaker 1>maintenance to development and testing environments those can absorb interruptions.

258
00:14:42.039 --> 00:14:45.320
<v Speaker 1>Use custom maintenance windows for production. Pick the least risky

259
00:14:45.399 --> 00:14:48.799
<v Speaker 1>day and hour, coordinate across GEO replicas, and treat those

260
00:14:48.799 --> 00:14:52.000
<v Speaker 1>settings like you would a surgical schedule. Test changes during

261
00:14:52.080 --> 00:14:55.759
<v Speaker 1>devpt boxes first system managed ones upgrade earlier in the

262
00:14:55.799 --> 00:14:58.440
<v Speaker 1>monthly cycle, giving you a preview of what could go

263
00:14:58.519 --> 00:15:02.639
<v Speaker 1>wrong before the same patches hit production. Also, don't romanticize

264
00:15:02.679 --> 00:15:06.519
<v Speaker 1>no downtime. Every patch reboots the underlying VM. That's a

265
00:15:06.559 --> 00:15:10.360
<v Speaker 1>physical law. The goal isn't elimination, its orchestration. Use read

266
00:15:10.399 --> 00:15:13.679
<v Speaker 1>replicas to shoulder load temporarily, or point applications through a

267
00:15:13.679 --> 00:15:17.200
<v Speaker 1>load balancer that retries connection attempts during maintenance cycles. A

268
00:15:17.240 --> 00:15:20.240
<v Speaker 1>few seconds of smart handling beat a minute of user outrage.

269
00:15:20.279 --> 00:15:23.919
<v Speaker 1>Finally recognize Microsoft's emergency clause. If the team in Redman

270
00:15:24.000 --> 00:15:27.159
<v Speaker 1>discovers a vulnerability that could turn your database into Swiss cheese,

271
00:15:27.240 --> 00:15:31.080
<v Speaker 1>maintenance becomes instantaneous. No one will email in advance, accept it,

272
00:15:31.320 --> 00:15:34.919
<v Speaker 1>architect accordingly, and stop being scandalized by surprise restarts. This

273
00:15:35.039 --> 00:15:39.279
<v Speaker 1>isn't malice, it's triage. So your rule of thumb automate resilience,

274
00:15:39.559 --> 00:15:43.360
<v Speaker 1>schedule predictably but designed for chaos. Maintenance isn't the villain.

275
00:15:43.399 --> 00:15:46.279
<v Speaker 1>Its entropy in uniform, and the more you understand its habits,

276
00:15:46.320 --> 00:15:49.080
<v Speaker 1>the less it costs you in lost sleep and lost revenue.

277
00:15:49.360 --> 00:15:52.360
<v Speaker 1>Next up, the self congratulatory feature everyone assumes will save

278
00:15:52.399 --> 00:15:55.600
<v Speaker 1>them from disaster backups. Spoiler alert, They're not the safety

279
00:15:55.639 --> 00:15:59.600
<v Speaker 1>net you think backups the false sense of security. Backups

280
00:15:59.639 --> 00:16:01.879
<v Speaker 1>make every you won't feel virtuous, like eating a salad

281
00:16:01.919 --> 00:16:04.440
<v Speaker 1>after three doughnuts. You don't quite fix the problem, but

282
00:16:04.440 --> 00:16:07.600
<v Speaker 1>at least you can claim to be responsible. Unfortunately, in

283
00:16:07.679 --> 00:16:11.600
<v Speaker 1>Azure Postgrasscial flexible server, that sense of security is mostly theater.

284
00:16:12.120 --> 00:16:15.679
<v Speaker 1>The defaults lull you in daily snapshots, seven day retention,

285
00:16:16.000 --> 00:16:20.480
<v Speaker 1>automatic rider headlog archiving every five minutes sounds bulletproof until

286
00:16:20.519 --> 00:16:23.320
<v Speaker 1>you realize those backups are stored with the resource. Delete

287
00:16:23.320 --> 00:16:26.120
<v Speaker 1>the server, and after a short grace period asure deletes

288
00:16:26.159 --> 00:16:29.200
<v Speaker 1>the safety. Along with it. Your disaster recovery plan just

289
00:16:29.200 --> 00:16:32.159
<v Speaker 1>got garbage collected. This happens because built in backups are

290
00:16:32.200 --> 00:16:34.960
<v Speaker 1>tied to the life cycle of the environment. They're designed

291
00:16:34.960 --> 00:16:38.840
<v Speaker 1>for short term rollbacks, not historical preservation. Microsoft's mentality here

292
00:16:38.879 --> 00:16:41.320
<v Speaker 1>is simple. If you wanted retention, you'd pay for it.

293
00:16:41.440 --> 00:16:44.440
<v Speaker 1>Seven days comes free because it's essentially cash extended to

294
00:16:44.480 --> 00:16:46.679
<v Speaker 1>thirty five, and you start paying for storage as though

295
00:16:46.679 --> 00:16:49.559
<v Speaker 1>you've hired an archivist who never forgets to invoice. Each

296
00:16:49.600 --> 00:16:52.840
<v Speaker 1>snapshot uses incremental storage. Only changed blocks are built, but

297
00:16:52.879 --> 00:16:55.399
<v Speaker 1>those changes pile up quickly once your database logs never

298
00:16:55.480 --> 00:16:58.159
<v Speaker 1>rest add w WEL files, and you're now paying per

299
00:16:58.200 --> 00:17:00.919
<v Speaker 1>gigabyte for the assurance that you might reach wind five minutes,

300
00:17:01.000 --> 00:17:03.960
<v Speaker 1>a comforting but expensive illusion. Then there's the other problem.

301
00:17:04.079 --> 00:17:07.799
<v Speaker 1>Snapshots are physical copies. They're useless if corruption creeps into

302
00:17:07.839 --> 00:17:11.880
<v Speaker 1>the data before backup time, logical errors, ransomware, rogue scripts.

303
00:17:11.920 --> 00:17:15.039
<v Speaker 1>Those replicate perfectly into each daily snapshot. It's a clean,

304
00:17:15.079 --> 00:17:19.519
<v Speaker 1>synchronized disaster. That's why professionals pair automated snapshots with logical

305
00:17:19.559 --> 00:17:22.559
<v Speaker 1>backups dumps of the database structure and data using something

306
00:17:22.680 --> 00:17:26.240
<v Speaker 1>like pg dump. Logical backups are slower but portable. You

307
00:17:26.279 --> 00:17:28.759
<v Speaker 1>can store them in a recovery service's vault or even

308
00:17:28.799 --> 00:17:31.680
<v Speaker 1>in long term cool storage, independent of the server's mortality.

309
00:17:31.799 --> 00:17:35.599
<v Speaker 1>They survive deletion, deliver, cross version, restore capability, and remarkably

310
00:17:35.640 --> 00:17:38.319
<v Speaker 1>cost less per year than weeks of premium snapshot storage.

311
00:17:38.359 --> 00:17:42.359
<v Speaker 1>You can mix both automatic snapshots for quick recovery monthly

312
00:17:42.480 --> 00:17:45.880
<v Speaker 1>logical dumps for long term compliance. Think of snapshots as airbags.

313
00:17:45.920 --> 00:17:48.759
<v Speaker 1>They save you from immediate impact, but logical dumps as insurance.

314
00:17:48.799 --> 00:17:51.799
<v Speaker 1>They rebuild the car. When evaluating retention, do the mass

315
00:17:51.799 --> 00:17:54.599
<v Speaker 1>no one does. A full year of thirty five day

316
00:17:54.640 --> 00:17:58.119
<v Speaker 1>rolling snapshots can outprice two years of cold tear blob storage.

317
00:17:58.119 --> 00:18:02.119
<v Speaker 1>Holding compressed secle dumps. The illusion of convenience costs more

318
00:18:02.119 --> 00:18:04.839
<v Speaker 1>than actual durability. The golden model is this. Let as

319
00:18:04.880 --> 00:18:07.359
<v Speaker 1>you take its nightly snapshots for short term rollback, but

320
00:18:07.440 --> 00:18:11.400
<v Speaker 1>automate monthly PG dump exports to storage vaults tagged for archival,

321
00:18:11.839 --> 00:18:14.640
<v Speaker 1>validate those dumps. Most teams never attempt a restore until

322
00:18:14.640 --> 00:18:18.279
<v Speaker 1>it's too late. Backups you've never tested are Schrodinger's safety net,

323
00:18:18.440 --> 00:18:21.519
<v Speaker 1>both valid and worthless. At the same time. Backups don't

324
00:18:21.559 --> 00:18:24.279
<v Speaker 1>exist to reassure you. They exist to recreate you. Treat

325
00:18:24.279 --> 00:18:26.680
<v Speaker 1>them like a lifeboat, not a frame certificate. And now

326
00:18:26.720 --> 00:18:30.039
<v Speaker 1>that you've secured the infrastructure, let's examine the real enemy,

327
00:18:30.359 --> 00:18:34.799
<v Speaker 1>human psychology psychology of cloud waste. Every burnt budget begins

328
00:18:34.799 --> 00:18:38.200
<v Speaker 1>with optimism. Admin's over provision, not because they're reckless, but

329
00:18:38.240 --> 00:18:41.240
<v Speaker 1>because fear of downtime outweighs fear of cost. Its survival

330
00:18:41.240 --> 00:18:44.880
<v Speaker 1>instinct disguised as best practice. The Azure portal feeds that

331
00:18:44.960 --> 00:18:49.640
<v Speaker 1>instinct beautifully. Every wizard offers recommended defaults phrase like divine revelation,

332
00:18:49.880 --> 00:18:54.279
<v Speaker 1>and most users exhausted by checkout fatigue, Except then anxiety

333
00:18:54.319 --> 00:18:57.880
<v Speaker 1>takes over. What if traffic spikes? What if dis claytoncy arises?

334
00:18:58.319 --> 00:19:01.359
<v Speaker 1>You stack on v coorse and I like emotional padding,

335
00:19:01.480 --> 00:19:05.279
<v Speaker 1>convincing yourself that money equals safety. What you've built isn't resilience,

336
00:19:05.319 --> 00:19:08.160
<v Speaker 1>it's expensive comfort. This is default bias in cloud form,

337
00:19:08.319 --> 00:19:11.279
<v Speaker 1>the belief that Microsoft's prelfilled boxes know your workload better

338
00:19:11.319 --> 00:19:14.319
<v Speaker 1>than you do. They don't. Defaults are designed to prevent

339
00:19:14.400 --> 00:19:19.200
<v Speaker 1>support tickets, not optimize invoices. Profiling, alerting and observable metrics

340
00:19:19.200 --> 00:19:23.480
<v Speaker 1>replace guesswork far better than recommended modes ever will. Bottom line,

341
00:19:23.559 --> 00:19:26.759
<v Speaker 1>your database doesn't need empathy, it needs measurement. And since

342
00:19:26.759 --> 00:19:29.759
<v Speaker 1>we've now traumatized your budget and your ego equally, let's

343
00:19:29.759 --> 00:19:32.240
<v Speaker 1>close with the one truth every engineer learns too late.

344
00:19:33.319 --> 00:19:36.079
<v Speaker 1>The real cost of set and forget as your postgrescol

345
00:19:36.079 --> 00:19:39.319
<v Speaker 1>flexible server isn't outrageously expensive. It becomes expensive the moment

346
00:19:39.359 --> 00:19:42.000
<v Speaker 1>you stop paying attention. The real cost isn't compute, its

347
00:19:42.000 --> 00:19:45.920
<v Speaker 1>complacency disguised as convenience, the moment you click next without reading.

348
00:19:46.240 --> 00:19:49.759
<v Speaker 1>Azure quietly drafts a recurring donation from your department's funds

349
00:19:50.000 --> 00:19:52.920
<v Speaker 1>to control costs. You control intent, pick tiers that match

350
00:19:52.920 --> 00:19:56.440
<v Speaker 1>observed workload, not hypothetical nightmares. Cap auto grows or access

351
00:19:56.480 --> 00:20:00.160
<v Speaker 1>capacity doesn't become permanent. Debt enable high availability only where

352
00:20:00.200 --> 00:20:03.119
<v Speaker 1>a single lost minute equals real financial damage. Use replicas

353
00:20:03.160 --> 00:20:06.279
<v Speaker 1>where they'll earn back their keep, not stand in decorative symmetry.

354
00:20:06.440 --> 00:20:09.119
<v Speaker 1>Tune maintenance windows before Microsoft does it for you at

355
00:20:09.119 --> 00:20:11.319
<v Speaker 1>three a m. And, for the love of logic, test

356
00:20:11.319 --> 00:20:14.279
<v Speaker 1>your backups before Destiny tests them for you. This entire

357
00:20:14.279 --> 00:20:17.279
<v Speaker 1>ecosystem sells peace of mind, but the invoice lists every

358
00:20:17.359 --> 00:20:20.759
<v Speaker 1>forgotten toggle you never questioned. Efficiency isn't in the pricing sheet,

359
00:20:20.799 --> 00:20:22.839
<v Speaker 1>It's in the discipline of those who read it. If

360
00:20:22.839 --> 00:20:26.279
<v Speaker 1>this breakdown saved your budget or your job, subscribe the

361
00:20:26.319 --> 00:20:27.359
<v Speaker 1>next fix could save both.