Please summarize this meeting as a structured Q3 cost-optimization alignment note for Emerging DB.

Include:

1. Key discussion points by product: Azure Cosmos DB, MongoDB vCore, Azure Managed Redis / Redis.
2. Cost-optimization ideas discussed, including SKU right-sizing, autoscale restriction, HA/geo-replica restriction, persistence removal, retention/logging review, unused resource cleanup, policy controls, and lower-environment guardrails.
3. Decisions made during the call.
4. Items agreed as potential Q3 objectives.
5. Items needing further analysis/refinement.
6. Dependencies, risks, or blockers identified.
7. Action items with owner, next step, and target timeline where mentioned.
8. Any open questions for PO or engineers.

Keep the summary concise, professional, and suitable to share with the team after the meeting.

Posted By Nikhil21:39

0

Continue Reading

 Do we have cost visibility around this

Are queries consuming high RUs due to poor filters or cross-partition scans?

Review oversized Redis/AMR instances.

Review Mongo vCore cluster sizing and usage patterns to ensure compute, storage, backup, and environment configuration are aligned with actual workload needs.

Do we have idle or rarely used clusters?

Is storage growing due to unused or test data?

Are diagnostic settings consistent across products?

Review diagnostic logging, metrics, and retention configuration to avoid unnecessary monitoring cost .

uncontrolled logging becomes expensive.

Do any Emerging DB non-prod resources support scheduled scale-down or reduced capacity during non-business hours?”

Objective: Review whether Cosmos containers are indexing all fields unnecessarily.

Why it matters: excessive indexing can increase RU consumption during writes.

“Can we review if Cosmos indexing policies are optimized, especially for containers with heavy write activity?”

Can we review memory utilization versus allocated SKU for Redis/AMR and identify right-sizing opportunities?”

Policy expiration review

Where we allow high SKU, HA, autoscale, persistence, or geo-replication by exception, can we add review/expiry so exceptions don’t stay forever?

Can we define standard lower-environment templates for Cosmos, vCore, and AMR so teams don’t accidentally provision production-like configurations?

Posted By Nikhil21:32

0

Continue Reading

 

Hi Team, thanks for joining.

The purpose of this call is to align on possible cost-optimization opportunities for Emerging DB and see what can be considered for Q3 objectives.

We are not trying to finalize everything today, but we should identify potential areas, understand feasibility, impact, effort, and any dependencies.

I’ll first request [PO Name] to share the expectation/business objective, and then we can go through inputs from the engineering side.

-

Ask PO:

“[PO Name], could you please share what outcome you are expecting from the cost-optimization objective for Q3?”

Also ask:

“Are we focusing mainly on lower environment cost, unused resources, SKU optimization, policy controls, or overall product cost?”

2. Ask engineers for ideas

Say:

“From engineering side, let’s discuss where we see cost-saving opportunities.”

Prompt them with examples:

“Do we see opportunities around SKU downgrade, autoscale restriction, HA/geo-replica restriction, persistence removal, unused resources, policy controls, or migration from higher-cost services?”

3. For each idea, ask these questions

“What is the current cost concern?”

“Which product and environment is impacted?”

“What change are we proposing?”

“What is the expected saving or benefit?”

“Any risk or user impact?”

“Is this policy, configuration change, analysis, or implementation?”

“Can this be taken in Q3, or does it need more refinement?”

4. Categorize items during the call

Use simple buckets:

“Let’s classify this as: Ready for Q3, Needs Analysis, Dependency/Blocked, or Parked.”

5. Close the call

Say:

“Thanks Team. I’ll summarize the discussed cost-optimization ideas with product, impact, feasibility, owner/context, and next step. For valid Q3 candidates, we can create or refine GitLab items and align with PO for priority.”

##

Alright , I will come to ___ next

Alright, moving on to the next topic

Got it, I’ll capture that. Any other input before we move to the next item?

Clear, we’ll proceed with that direction

Posted By Nikhil18:14

0

Continue Reading

Title: Emerging DB Q3 Planning Discussion

Hi Team,

I am setting up this discussion to align on the Emerging DB areas we can realistically take forward and deliver in this quarter.

The objective is to hear from the engineers on possible implementation areas, understand the effort and feasibility, and also assess the expected cost benefits or value from each item.

Agenda:

• Discuss potential Emerging DB initiatives for this quarter

• Identify what can be implemented and delivered within Q3

• Understand effort, dependencies, and risks

• Estimate expected cost benefits or operational value

• Agree on next steps and ownership

Regards,
Nikhil

Posted By Nikhil06:38

0

Continue Reading

 

Issue 1 Title:
RBAC | Prepare Flowchart for Role Assignment for Human and Technical Users

Story:
As a developer,
I want to prepare a flowchart for RBAC role assignment covering both human users and technical users,
so that the role assignment process is clearly documented and can be reviewed before implementation/onboarding.

Description:
This task is to document the end-to-end role assignment flow for human users and technical users. The flowchart should explain how access requests are initiated, validated, approved, and assigned through the RBAC process.

Acceptance Criteria:

• Flowchart is prepared for human user role assignment.
• Flowchart is prepared for technical user role assignment.
• Approval/request flow is clearly captured.
• Any dependency or open question is documented.
• Flowchart is reviewed with the team and linked in the issue.

Posted By Nikhil05:54

0

Continue Reading

 Here is a stronger, more current version you can use:

Database Reliability Engineer / SRE with strong experience across Oracle, PostgreSQL, and emerging database platforms, focused on reliability, resilience, automation, observability, and operational excellence.

Working as Scrum Master for the Emerging Database team, driving agile delivery, backlog refinement, sprint planning, blocker tracking, stakeholder alignment, and cross-functional coordination with engineers, Product Owners, Reliability Owners, and vendor teams.

Hands-on experience in Oracle and PostgreSQL operations, including performance diagnostics, query optimization, AWR/ADDM/Wait Event analysis, backup and recovery, Data Guard, RMAN, GoldenGate, Flashback, PITR, and HA/DR workflows.

Strong background in database SRE practices, including monitoring, alerting, incident reduction, automation of repetitive operational tasks, proactive risk identification, and continuous improvement of platform stability.

Contributing to observability initiatives by improving database visibility through metrics, dashboards, alerts, and reporting solutions that help teams identify issues earlier and reduce operational risk.

Experienced in business continuity and resilience activities, including BCM/BCP execution, failover readiness, recovery validation, evidence collection, and automation-led operational controls.

Designed and implemented automation solutions to reduce manual effort, improve consistency, minimize human error, and accelerate resolution of operational issues across database environments.

Actively involved in backup governance, patching support, RCA follow-ups, operational reporting, and capacity/performance reviews for mission-critical database platforms.

Applied data modelling, data mining, and ML/NLP-enabled analytical workflows to extract insights from structured and unstructured data, supporting ticketing workflow improvements and operational decision-making.

Collaborates closely with product managers, developers, engineering teams, and management stakeholders to translate technical issues into clear actions, risks, decisions, and delivery outcomes.

Brings a balanced mix of deep database engineering expertise, SRE mindset, agile delivery discipline, and stakeholder management to support reliable, scalable, and resilient data platforms.

You can remove the older/basic lines like “installation, configuration” and avoid repeating ML/NLP twice. This version sounds more aligned to Scrum Master + SRE + Observability + Current DBA/SRE work.

Posted By Nikhil06:07

0

Continue Reading

 

Title:
AMR | Remove Persistence Settings from Lower Environment Clusters

Story:
As a developer,
I want to identify and remove unnecessary persistence settings such as AOF/RDB from AMR/Redis clusters in lower environments,
so that Dev/Test/UAT clusters do not incur unnecessary storage and I/O costs.

Description:
Persistence settings are currently enabled on some AMR/Redis clusters in lower environments. Since these environments may not require persistent storage for non-production workloads, the enabled persistence configuration can lead to additional storage and I/O cost.

This item is to analyze the impacted AMR/Redis clusters, confirm where persistence is not required, and remove/disable the persistence settings after validation. The activity should be aligned with the product/team requirements to avoid any impact to required testing or recovery scenarios.

Scope:

• Identify AMR/Redis clusters where persistence settings are enabled.
• Confirm impacted lower environments such as Dev, Test, and UAT.
• Validate whether persistence is required for each cluster.
• Remove/disable unnecessary AOF/RDB persistence settings.
• Capture validation evidence after the change.

Acceptance Criteria:

• Impacted clusters with persistence enabled are identified.
• Confirmation is received that persistence is not required for selected lower environment clusters.
• Persistence settings are removed/disabled where applicable.
• Post-change validation is completed.
• Evidence/comments are updated in the GitLab issue.

Posted By Nikhil01:59

0

Continue Reading